|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 6
Note that Java Tip 130's Sizeof class requires a quiescent JVM (so that the heap activity is only due to object allocations and garbage collections requested
by the measuring thread) and requires a large number of identical object instances. This does not work when you want to size
a single large object (perhaps as part of a debug trace output) and especially when you want to examine what actually made
it so large.
The discussion above highlights a philosophical point: given that you usually deal with object graphs, what is the definition of an object size? Is it just the size of the object instance you're examining or the size of the entire data graph rooted at the object instance? The latter is what usually matters more in practice. As you shall see, things are not always so clear-cut, but for starters you can follow this approach:
Note: Implementing any Java interface merely marks the class in question and does not add any data to its definition. In fact, the JVM does not even validate that an interface implementation provides all methods required by the interface: this is strictly the compiler's responsibility in the current specifications.
To bootstrap the process, for primitive data types I use physical sizes as measured by Java Tip 130's Sizeof class. As it turns out, for common 32-bit JVMs a plain java.lang.Object takes up 8 bytes, and the basic data types are usually of the least physical size that can accommodate the language requirements
(except boolean takes up a whole byte):
// java.lang.Object shell size in bytes:
public static final int OBJECT_SHELL_SIZE = 8;
public static final int OBJREF_SIZE = 4;
public static final int LONG_FIELD_SIZE = 8;
public static final int INT_FIELD_SIZE = 4;
public static final int SHORT_FIELD_SIZE = 2;
public static final int CHAR_FIELD_SIZE = 2;
public static final int BYTE_FIELD_SIZE = 1;
public static final int BOOLEAN_FIELD_SIZE = 1;
public static final int DOUBLE_FIELD_SIZE = 8;
public static final int FLOAT_FIELD_SIZE = 4;
(It is important to realize that these constants are not hardcoded forever and must be independently measured for a given
JVM.) Of course, naive totaling of object field sizes neglects memory alignment issues in the JVM. Memory alignment does matter
(as shown, for example, for primitive array types in Java Tip 130), but I think it is unprofitable to chase after such low-level
details. Not only are such details dependent on the JVM vendor, they are not under the programmer's control. Our objective
is to obtain a good guess of the object's size and hopefully get a clue when a class field might be redundant; or when a field
should be lazily populated; or when a more compact nested datastructure is necessary, etc. For absolute physical precision
you can always go back to the Sizeof class in Java Tip 130.
To help profile what makes up an object instance, our tool will not just compute the size but will also build a helpful datastructure
as a byproduct: a graph made up of IObjectProfileNodes:
interface IObjectProfileNode
{
Object object ();
String name ();
int size ();
int refcount ();
IObjectProfileNode parent ();
IObjectProfileNode [] children ();
IObjectProfileNode shell ();
IObjectProfileNode [] path ();
IObjectProfileNode root ();
int pathlength ();
boolean traverse (INodeFilter filter, INodeVisitor visitor);
String dump ();
} // End of interface
IObjectProfileNodes are interconnected in almost exactly the same way as the original object graph, with IObjectProfileNode.object() returning the real object each node represents. IObjectProfileNode.size() returns the total size (in bytes) of the object subtree rooted at that node's object instance. If an object instance links
to other objects via non-null instance fields or via references contained inside array fields, then IObjectProfileNode.children() will be a corresponding list of child graph nodes, sorted in decreasing size order. Conversely, for every node other than
the starting one, IObjectProfileNode.parent() returns its parent. The entire collection of IObjectProfileNodes thus slices and dices the original object and shows how data storage is partitioned within it. Furthermore, the graph node
names are derived from the class fields and examining a node's path within the graph (IObjectProfileNode.path()) allows you to trace the ownership links from the original object instance to any internal piece of data.
You might have noticed while reading the previous paragraph that the idea so far still has some ambiguity. If, while traversing the object graph, you encounter the same object instance more than once (i.e., more than one field somewhere in the graph is pointing to it), how do you assign its ownership (the parent pointer)? Consider this code snippet:
Object obj = new String [] {new String ("JavaWorld"),
new String ("JavaWorld")};
Each java.lang.String instance has an internal field of type char[] that is the actual string content. The way the String copy constructor works in Java 2 Platform, Standard Edition (J2SE) 1.4, both String instances inside the above array will share the same char[] array containing the {'J', 'a', 'v', 'a', 'W', 'o', 'r', 'l', 'd'} character sequence. Both strings own this array equally, so what should you do in cases like this?
If I always want to assign a single parent to a graph node, then this problem has no universally perfect answer. However, in practice, many such object instances could be traced back to a single "natural" parent. Such a natural sequence of links is usually shorter than the other, more circuitous routes. Think about data pointed to by instance fields as belonging more to that instance than to anything else. Think about entries in an array as belonging more to that array itself. Thus, if an internal object instance can be reached via several paths, we choose the shortest path. If we have several paths of equal lengths, well, we just pick the first discovered one. In the worst case, this is as good a generic strategy as any.
Archived Discussions (Read only)