|
| Re: What does the objectid mean? [message #8659 is a reply to message #8641] |
Thu, 05 February 2009 12:51   |
 Andreas Buchen
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Hi Kristof,
in terms of terminology: the object address is the physical address of the
objects as used by the VM. We always print the object address as hex code.
Internally, for performance reasons MAT uses consecutive integers to
identify objects (less space than longs). That is what we call object id,
but this is what you only see if you work with the API directly.
Because the object address is the physical address, and because the
garbage collector moves objects around, and because the VM does a full
garbage collection before writing a heap dump, it is extremely difficult
to find identical objects in two heap dumps. Just looking at the object on
the heap, it is not possible to tell whether it was just moved from eden
space to survivor space or whether it was newly created.
The compare functionality currently build-in therefore only compares
aggregated numbers: the histogram by class, and the histogram by class
loader.
However, if you know that the objects are identical, a different object
address should not bother you. We have compared dumps and after a very
short period of (busy) time we could only find 1 per cent of the object
back in the heap.
Andreas.
|
|
|
| Re: What does the objectid mean? [message #8681 is a reply to message #8659] |
Thu, 05 February 2009 18:03 |
Kristof Szabados
Messages: 82
Registered: July 2009 |
Member |
|
|
Hi,
Thank you for the information.
I was expecting that the VM might move around the objects, which might
therefore change their phisical address.
It would be a very nice feature if the memory analyzer could somehow
detect those objects which are possibly different.
For example if you have 16000 object at one time and 16004 a few seconds
later, it would be priceless if the tool could show me the 4 new objects
(but even if it could decrease the numbers to about a 100 objects that
would also save the day).
With these real life numbers I know that if those 4 objects (or 100
possibly new/deleted) were identified, I could analyze why and where
they were created and solve the problem.
But analyzing 16000, it is just too much.
It might be just me, but as most of my object are stable in my program
(I create 99.9% of them at once and never replace/release them), I guess
that the VM might just stop moving them around after a time.
/* I don't know if the VM is clever enough for this, but moving around
objects that never change is not an optimal behavior.*/
So maybe the memory analyzer could check how many of the objects might
have stayed in one place, and offer to filter them out.
Even if this is not precise and 1-2% percent of the objects is reported
as possibly new/deleted, or one would have to have several heapdumps (to
catch a timeframe, where the objects were not moved), this would
certainly help a lot.
Does a feature like this exist already?
/* and I have missed it*/
Or if not are there plans for such a feature ?
Best Regards
Kristof
|
|
|
| Re: What does the objectid mean? [message #8693 is a reply to message #8681] |
Thu, 05 February 2009 19:36 |
Andreas Buchen
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Hi Kristof,
you're right - once objects have been moved the old gen, they should not
be moved around too much anymore. A compacting full GC would also move
those objects. And then, of course, it depends on the type of application.
We're looking mostly at request/response-oriented server applications.
Here quite a lot of objects are created and almost immediately thrown
away. Desktop applications can behave differently.
As I said, we tried to identify identical objects on the objects address.
The result is not usable in any practical way. I personally was surprised
to find out that the number was so low! We tried to identify objects based
on the reference path, and attribute names. The results are better, but
still only some 30 per cent. And it is very costly (in terms of processing
power) to do so. So thinking of your 10.000 objects, still some 7.000
cannot be identified. That is still way too much for manual analysis. The
results vary, however, very much by the type of class - some classes can
be matched relatively good, some not.
We plan to build this kind of compare functionality into the Memory
Analyzer for sure. Many people ask for this feature. We just haven't found
the lever to get much practical value out of it (at least if you need/want
to go down to the object level). Ideas are very much welcome. JSR 326,
which is looking at post-mortem JVM diagnostics, is also looking into
that. Maybe we will get some help from the VM itself.
Andreas.
|
|
|
Powered by
FUDForum. Page generated in 0.03442 seconds