how can I do java object allocation tracing from with code

Question

I'm using java profilers to check GC performance - but its very hit and miss. What I'd really like to do is to embed some real world profiling into my app. It's very easy for time profiling - ie marking time and subtracting, but I can't find any way of doing it from memory.

Essentially - I want to make a function like this:

 ProfileResult  profile( Runnable function)

that gives me back information about memory allocation - ie how many objects, how many bytes were allocated - and how much of that could be garbage collected.

What I want to end up with is tests in our CI system that basically get upset at things like function has increased its memory pressure... and that are definitively correct - they actually know that this new function allocates 200 bytes more than the old one - its not just a random snap of time where all sorts of other things could happen in other threads, or garbage collections could have happened or whatever.

Is this possible? I know the JVM has profiling functionality built in - is it possible to access it from within the program which is running - or is there any other way to achieve what I want?

Answer 1

Analysis of JVM heap dumps can be integrated into CI and (hypothetically) give you all information you are looking for.

Idea is simple, you are taking heap dump before and after function being tested. Then you can analyze difference and assert certain SLA of code being tested.

In past, I was automated heap dump analysis to verify correct resource disposal. Some utility code is available as open source https://github.com/aragozin/heapunit/ . Though, that library does not support heap diff based analysis.

Using heap dump based approach may have other down sides

• performance / disk space usage if you JVM have large heap
• in accurate object allocation profiling in GC is invoked between two dumps

If you need just track amount of bytes allocated by piece of code on single thread take a look on this snippet of code it is using per thread allocation counter available via JMX.