|
|
|
|
Back to newsletter 166 contents
I recently needed to get a sizeof implementation for Java objects. I needed to get a "deep" size, so that I could see how much memory a particular object was retaining. So I searched for implementations and found several different approaches. I ignored the ones that needed to use native calls of one type or another, I was looking for a Java implementation; and I found three main types of implementations.
Firstly, there's the old "use reflection and guess based on the known primitive data sizes and overheads" technique, which goes back about 15 years, though seems to have been most popularised by some Javaworld articles (see the tools section below for that and all the rest). Next is the "agent" based technique which Heinz Kabutz first popularised in his newsletter about 7 years ago. And lastly, more recently, are "unsafe" techniques developed in the last few of years.
After going through them, I tested them for my purposes and found that the carrotsearch 'unsafe' one was both the fastest and churned the least memory (ehcache's 'unsafe' implementation was close).
Note the drawback is that using unsafe is potentially dangerous - if the implementation is flakey or the JVM internals change, it'll most likely crash the JVM. Whenever using 'unsafe' based tools, it's worth bearing in mind Gil Tene's graphic description of using unsafe: like using scissors which have the obvious warning label saying "not safe for poking at one's own eye" to then poke at an itch in your eye.
See the tools section below for the links to those sizeof tools, and see all our usual sections: links to articles, news and as ever, all the extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
(Note the Lucene one is not listed as the carrotsearch one is an extracted version of that.)
Back to newsletter 166 contents
