Hi Anton,
thank you for the quick reply and the effort to explain this.
Please consider the following scenario which explains what actually happens:
....
3) JVM goes on, enters the application entry point, the application starts running... As the result, M objects are created. They are yet unassigned to any generation.
4) You explicitly advance the generation, or capture a snapshot. These M objects are assigned to "#2: Marked by user" or "#2. Captured snapshot ...", respectively.
...
So what you're saying: the newly bumped generation assigned to all existing objects that don't have any previous generation assigned to them?...
..which the only meaningful option I can imagine apart from the "bump the counter, all newly created objects will pick that one up", ie no-mass changing modification of records are necessary -- and this is definitely the way I understood from the tooltip and documentation..
Looks like the text in the tooltip and the help are not very correct, and we should rework them.
Yes, again I found them quite clearly and unambiguosly suggesting the other interpretation above.
2) I hope the explanation above covers this case.
Well, if I run the above program - actually a modified version:
Code: Select all
public class TryMain {
Object data = new byte[2500];
public static void main(String[] args) throws IOException {
System.out.println("please advance generation : gen #2, hit enter"); System.in.read();
System.out.println("take a memory snapshot now: gen #3, hit enter"); System.in.read();
System.out.println("please advance generation : gen #4, hit enter"); System.in.read();
TryMain d = new TryMain();
System.out.println("allocated TryMain");
System.out.println("please advance generation : gen #5, hit enter"); System.in.read();
System.out.println("take a memory snapshot now: gen #6, hit enter"); System.in.read();
System.out.println(d);
}
}
If understand your version correctly (yet unassigned objects added to new gen), the data object should end up in the generation created just after the allocation: gen #5.
Now that I ran the above again, it's actually gen #4 which I originally assumed... but it seemed I got different results than that earlier, like it ended up in get#1 "starting the agent" which seemed definitely wrong. Not sure what I did differently there then but I cannot reproduce it right now.
So sorry but now it seems the help and the tooltip was right after all - new objects will belong to the generation last created..
In this case however, I don't really understand how the snapshot-created generations can contain any real objects in their respective snapshots (e.g "#2 snapshot" generation which is listed within the that same snapshot file).
3) Any way to use Eclipse debugger + YJP attach mode? It largely seems to work, but may break generation numbers?
Sorry, I don't understand your question. Could you please provide more detail.
[/quote]
Sure, I meant running my code in a debugger, then attaching the profiler (eg while it's stopping at a breakpoint), increment generations, step through code, take a snapshot, compare.
E.g take the above program, remove the System.in.read()-s, step through instead by debugger.
The reason I'm asking is, this seems basically working but I'm not sure how reliable it is (e.g if all threads are suspended, how is the agent executing profiler commands.. but maybe I'm misguided).
I was thinking of the strange behaviour like above(like when my object is assigned to the gen #1, even though there was definitely a later one before the object was created) was because the clash between the debug and profiler agent