Fully featured low overhead profiler for Java EE and Java SE platforms.
Ultimate profiling and monitoring solution for Gradle, Maven, Ant, JUnit and TestNG.
Easy to use performance and memory profiler for .NET framework.

Object Sizes and IntPtr fields.

Moderators: Vladimir Kondratyev, Anton Katilin

Object Sizes and IntPtr fields.

Postby JeremyK » Thu May 29, 2014 8:05 pm

This probably ends up as being 2 feature requests. I'm attempting to understand where the memory is going in a "fat" WinForms .Net 2.0 (32-bit) app.

So, I see a bunch of these (all of them are reported as 24 bytes, though the IntPtr value differs):

System.Drawing.Bitmap 24 24
nativeImage = IntPtr 155856136 0x094A2D08 4

I can understand the 24 byte value:
8 bytes object overhead
1 field inherited from System.MarshalByRefObject
3 fields inherited from System.Drawing.Image

I can understand why YourKit doesn't know what to do with that IntPtr. Yet, it seems misleading as well
to report a memory consumption of 24, when the actual value is rather higher. So, I guess my questions/feature requests are:

1) For .Net objects that contain "IntPtr" fields, could their sizes be somehow decorated to indicate that we're not really sure of the size. E.g., perhaps the above could say something like "24+". (Although I
suppose this "at least this big, possibly more" indicator would flow through all of the object size calculations.).

2) Perhaps the profiler could have some sort of 'plugin' interface where one could register some sort of extension assembly/dll for certain classes, such that if I knew that the above was, say, an HBITMAP, I could call some Windows function to get the size, and then adjust the size value that YourKit would use.
(I would assume this would have to happen in the actual profiler, since a raw memory address wouldn't mean anything to the UI).

Alternatively, perhaps the UI could have some sort of configuration that said: "If you see a non-zero IntPtr field named XXX in class YYY, then assume its ZZZ bytes" (though I'm not sure how useful that would be).

Thanks,

Jeremy
JeremyK
 
Posts: 7
Joined: Wed May 28, 2014 8:45 pm

Re: Object Sizes and IntPtr fields.

Postby Anton Katilin » Wed Jun 04, 2014 7:59 am

Hi Jeremy

You are right, the profiler uses CLR profiling API which reports only the managed objects, and provides no information about referenced memory allocated outside the CLR heap.

1) It's a great idea, and we've added a feature request.

2) Theoretically this approach would work. In practice, writing a plugin is a difficult task, and unlikely many users will spend their time in learning how to do it and then actually doing it. It would be a solution for experts.

Alternatively, perhaps the UI could have some sort of configuration that said: "If you see a non-zero IntPtr field named XXX in class YYY, then assume its ZZZ bytes" (though I'm not sure how useful that would be).

Sizes may differ for instances of the same class too. I don't think a reasonable estimation of the "added" size can be made. Creating a precise "size model" seems a difficult, if ever possible task.

Instead of statically assuming the native sizes, perhaps we could utilize an event driven model of measurement, that is to measure how the process memory size changes when objects of particular classes of interest are created.

It is similar to object allocation recording, but not the same:
http://www.yourkit.com/docs/java/help/allocations.jsp

For example, I can think of using the triggers:
http://www.yourkit.com/docs/java/help/triggers.jsp
Let's assume that there is a class Foo whose method bar() (or a constructor) is known to allocate native memory. We can create a trigger on Foo.bar() invocation to log the process memory size on the method enter and exit, as well as, if necessary, the thread and stack where the method was called. The logged deltas can be used to estimate native memory impact of the objects.

It's just an idea. There are many details to think of. For example, how to handle impact of multithreading, how to split the total process memory size delta to the native part and the size of the managed heap which possibly changes too as the result of calling Foo.bar(), etc. But if this approach is good in general, we can think about the detail more thoroughly.

Best regards,
Anton
Anton Katilin
 
Posts: 5575
Joined: Wed Aug 11, 2004 8:37 am


Return to .NET Profiler

Who is online

Users browsing this forum: No registered users and 1 guest