StackHolder - Jakub Kubrynski

Even today (and it's 2015) we have two versions or Oracle HotSpot JDK - adjusted to 32 or 64 bits architecture. The question is do we really would like to use 32bit JVM on our servers or even laptops? There is pretty popular opinion that we should! If you need only small heap then use 32bits - it has smaller memory footprint, so your application will use less memory and will trigger shorter GC pauses. But is it true? I'll explore three different areas: Memory footprint GC performance Overall performance Let's begin with memory consumption. Memory footprint It's known that major difference between 32 and 64 bits JVM relates to memory addressing. That means all references on 64bit version takes 8 bytes instead of 4. Fortunately JVM comes with  compressed object pointers  which is enabled by default for all heaps less than 26GB. This limit is more than OK for us, as long as 32 bit JVM can address around 2GB (depending on target OS it's still about 13 times l...

I've always been missing possibility to configure custom headers in JStat . Of course there are a lot of predefined data sets, but it'll be nicer if we could create our own data set. And as you probably already devised I'm writing this post because such functionality is of course available :) Unfortunately I haven't found it in any documentation so now I'll try to fill this gap. First thing we have to do is to provide custom descriptor with possible JStat options. This descriptor is just a text file containing something we'll call "jstat specification language". To make this custom file available to JStat we should place it in the following path: $HOME/.jvmstat/jstat_options If you want to view the bundled options please refer to  file in OpenJDK repository . The specification language is pretty similar to json files, and it contains the group of option  elements. Each option should be threaten as a set of columns that can be shown in single jsta...