We Keep Coding

How JVM GC know if a item on stack is a reference? [duplicate]

I read from some documents that Hotspot VM utilizes a data structure called Oop Maps to manage all OOPs in VM. My question is that when does this Oop Map data structure generated? At compile time or runtime? Any further detailed documents regarding to this will be more than welcomed. Thank you guys.

OopMap is a structure that records where object references (OOPs) are located on the Java stack. Its primary purpose is to find GC roots on Java stacks and to update the references whenever objects are moved within the Heap.
There are three kinds of OopMaps:
OopMaps for interpreted methods. They are computed lazily, i.e. when GC happens, by analyzing bytecode flow. The best reference is the source code (with lots of comments), see generateOopMap.cpp. InterpreterOopMaps are stored in OopMapCache.
OopMaps for JIT-compiled methods. They are generated during JIT-compilation and kept along with the compiled code so that VM can quickly find by instruction address the stack locations and the registers where the object references are held.
OopMaps for generated shared runtime stubs. These maps are constructed manually by the developers - authors of these runtime stubs.
During GC JVM walks through all thread stacks. Each stack is parsed as a stream of stack frames. The frames are either interpreted or compiled or stubs. Interpreted frames contain information about Java method and bci (bytecode index). OopMapCache helps to find an OopMap corresponding to the given method and bci. The method of a compiled frame is discovered by instruction address lookup.

How to analyze MAT with eclipse

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.

See all objects in some running JVM

I have a large distributed application with 20,000+ objects. I would like to be able to connect to this running JVM externally and view any arbitrary object and its attributes at any time.
For example, if I have some object instance from the following class
class Temp {
int attribute = 0;
String name = "John";
}
I would like to be able to connect to the JVM and see all instances of this class and its attribute and name values.
I believe this would be possible with a heap dump, but this would be extremely expensive given the application. Also, analyzing such a heap dump is extremely challenging when the size is in the 1GB+ range. Is there some other utility that can provide a triggered snapshot of all objects? Or perhaps a more clever solution to my problem?
I've looked into JConsole and the Java Flight Recorder but these do not provide the features I need. Any other suggestions?

OQL to find instances implementing java.security.Principal

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()}")

How can I access Java heap objects without a reference?

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