To my regular readers, you will recognise it as a an evolution of AllocationMonitor which I described in this post. For the history of the project and an explanation of some of the some of the concepts I refer you to that post.
So what is ByteWatcher?
In a sentence, ByteWatcher monitors your allocation and alerts you when a specified allocation limit is breached.
Regression testing is important. I don't think that there are many projects these days that are not filled to the brim with unit tests. Often the amount of code in the test branch of a project will far exceed the code in the main branch.
Principally we test:
- That functionality has not been broken.
- For certain programs it is important to test that the the code has not slowed down.
- For others programs that the size of the distribution has not exceeded a given amount.
But there is another attribute that you might want to test which is your program's allocation.
I've written a few posts on the problems and effects of allocation, see here for example. First rule of performance optimisation, Revisiting the First Rule of Performance Optimisation: Effects of Escape Analysis and A Case Study in Analysing Latency: Lock vs Synchronized.
For those programs where real-time (and therefore predictable latencies up to the high percentiles) is critical, allocation can be disastrous. The reason for this is that your allocations will, at some point, have to be garbage collected. A GC will cause a pause that will kill your predictable latencies. (There are other reasons to avoid allocation and I refer you to the links above for those).
With ByteWatcher you can add a couple of lines into your regression tests that will check whether the expected allocation has been exceeded or not. The documentation for getting the code and example usage is all in the README of the project but this is the basic structure.
Hope you find ByteWatcher useful and I welcome any feedback or contributions to the project.
Also thank you to Chris Newland (Mr JITWatch) for your help on some of the trickier allocation spikes we were seeing. I'll leave those for another post.