Category Archives: Java

Memory Mapped Files in Java

Important Facts about Memory Mapped files in Java – thanks to Java Revisited @ Blogspot

  1. Java supports Memory mapped IO with java.nio package.
  2. Memory mapped files is used in performance sensitive application, e.g. high frequency electronic trading platforms.
  3. By using memory mapped IO, you can load portion of large files in memory.
  4. Memory mapped file can result in page fault if requested page is not in memory.
  5. Ability to map a region of file in memory depends on addressable size of memory. In a 32 bit machine, you cannot access beyond 4GB or 2^32.
  6. Memory mapped IO is much faster than Stream IO in Java.
  7. Memory used to load File is outside of Java heap and reside on shared memory which allows two different processes to access File.
  8. Reading and writing on memory mapped file is done by operating system, so even if your Java program crashes after putting content into memory, it will make to File until OS is fine.
  9. Prefer Direct Byte buffer over Non Direct Buffer for faster performance.
  10. Don’t call MappedByteBuffer.force() method too often, this method is meant to force operating system to write content of memory into disk, So if you call force() method each time you write into memory mapped file, you will not see true benefit of using mapped byte buffer, instead it will be similar to disk IO.
  11. In case of power failure or host failure, there is slim chance that content of memory mapped file is not written into disk, which means you could lose critical data.

Leave a comment

Filed under Java

The Core of Microprocessors

Most modern computers today operate with multiple processors and the processor in-turn have multiple cores. Below is a breakdown of the architecture of a modern computer / processor. I took these notes so that it’s easy for me to understand and I hope it helps others.

Motherboards have  sockets that can fit Microprocessors  ( usually 2 )

Each Microprocessor has multiple computing components, which are actual independent central processing units also known as “Cores” ( usually 6 per socket ) . These cores share some computing functions like floating point calculations, while performing integer calculations independently.

Intel introduced the concept of Hyper-Threading. For each processor core that is physically present, the operating system addresses two virtual or logical cores, and shares the workload between them when possible.  ( usually there are 2 Hyper-Threads per core ).

When you issue the command like “procinfo” to list the number of CPU’s in a server (Linux/Unix ) . The number of CPU might be misleading as the command identifies each Hyper-Thread as a core. Hence A server with 2 sockets and 6 core processor in each socket will be reported to have 24 CPU’s. This is correct from OS perspective as OS treats each Hyper-Thread as a CPU.

Depending on the hardware architecture there can be multiple levels of caches based. The block diagram below describes the association of cache/memory  to processing units in a server.



Leave a comment

Filed under Hardware, JVM, Linux

GC metrics you should care

  • gen0(s)     – young gen collection time, excluding gc_prologue & gc_epilogue.
  • gen0t(s)    – young gen collection time, including gc_prologue & gc_epilogue
  • gen0usr(s)  – young gen collection time in cpu user secs
  • gen0sys(s)  – young gen collection time in cpu sys secs
  • gen1i(s)    – train generation incremental collection
  • gen1t(s)    – old generation collection/full GC
  • cmsIM(s)    – CMS initial mark pause
  • cmsRM(s)    – CMS remark pause
  • cmsRS(s)    – CMS resize pause // rarely look. Probably we set OG at fixed size
  • GC(s)       – all stop-the-world GC pauses
  • cmsCM(s)    – CMS concurrent mark phase   // don’t care
  • cmsCP(s)    – CMS concurrent preclean phase // don’t care
  • cmsCS(s)    – CMS concurrent sweep phase // don’t care
  • cmsCR(s)    – CMS concurrent reset phase // don’t care
  • alloc(MB)   – object allocation in MB (approximate***)
  • promo(MB)   – object promotion in MB (approximate***)
  • used0(MB)   – young gen used memory size (before gc)
  • used1(MB)   – old gen used memory size (before gc)
  • used(MB)    – heap space used memory size (before gc) (excludes perm gen)
  • commit0(MB) – young gen committed memory size (after gc)
  • commit1(MB) – old gen committed memory size (after gc)
  • commit(MB)  – heap committed memory size (after gc) (excludes perm gen)
  • apptime(s)  – amount of time application threads were running
  • appstop(s) – amount of time application threads were stalled
  • safept(s)   – amount of time the VM spent at safepoints (app threads stopped)

Leave a comment

Filed under JVM

Hugepages and Java

As a data point, at a previous employer we played a little with the use of HugePages and memory mapped files in an attempt to get better performance.
Java’s support for the use of HugePages is on a best effort basis and our experimentation found that java was initially using the HugePages, but over time (a few hours), the HugePages were no longer used by the JVM—thus effectively reducing the available amount of RAM by the amount allocated for HugePages. We ended up disabling HugePages for our usage. I do not recall any concern/investigation about the Anonymous huge pages.
In the above case, however, we were constantly changing the memmapped files (these were large image files), since each request would access different image files, and the files were accessed over network storage.

Leave a comment

Filed under JVM, Linux

Useful links for Regular Expression (RegEx) in Java

Regular Expression RegEx is one of the unsung heros in application development, it does not have the same appeal as terms like “pattern recognition”. Many developers are not comfortable admitting to customers that they use regular expression for extracting or manipulating data.

Regular expression is more popular among scripting languages like perl or python. Since these languages are usually used for developing internal tools, regular expressions are not a taboo and are freely used.

There are legitimate concerns about using regular expressions in  applications as they introduce dependence on the format of data and hence making your application vulnerable to changes in data format.

But if you know that your data format will not change frequently you can try using regular expressions in your code. If you are interested the following resources are a good place to start.

Reference :

Regular Expression Primer

Regex Patterns in Java


Leave a comment

Filed under Java

JVM parameters You should Know

Here are some commonly used JVM parameters that every application developer should review, some may be appropriate for your application, some may not.

This post is a quick reference for these parameters, please refer to the official java docs for complete technical documentations.

-Xms -Xmx

e.g. -Xms16g -Xmx16g

The min and max of your heap size. When you set them the same, you fixed the size which helps avoid any change in real time, but of course you want to make sure you don’t waste the size. NOTE: If you use a big heap ( or are using large page size ( default is 4KB ), consider using -XX:+AlwaysPreTouch also.

When you set this, in your GC log you will start seeing entries like

  • Total time for which application threads were stopped: 0.0002480 seconds
  • Total time for which application threads were stopped: 0.0001090 seconds

It reports the duration of time when your application is paused due to any kind of GC activity, and is used as another meter to measure your application throughput of the system CPU.

It prints the GC in details in old gen, young gen and perm gen. Your gc log won’t be very useful without this.

It prints the timestamp of GC event, without this, the only timestamp would be the time since the application start.

This reports the tenuring statistics (how old the objects are) and the desired threshold of when objects will be promoted. This information gives you insight of how long your application may be holding on to objects.

-XX:NewSize -XX:MaxNewSize (or use -XX:NewRatio )
e.g. -XX:NewSize=4096m -XX:MaxNewSize=4096m

The min and max size of young gen. Alternatively, you can use NewRatio to specify the size of the young gen relative to the size of the entire heap. e.g. -XX:NewRatio=4 means 1GB will be designated as young gen in a 4GB heap (where old gen is about 3GB + perm gen).


e.g. -XX:SurvivorRatio=2

The young gen is comprised of eden space and 2 survivor spaces, the survivor ratio specifies the size of the survivor space relative to the eden space. e.g. if you have a 4GB young gen and survivor ratio is 2, then your eden space is 2GB and each of your survivor space has 1GB in size. In other words, your survivor space size = ( size of young gen / ( SurvivorRatio + 2 ) ). The ratio can be tuned for your application, the smaller the survivor space, the fewer iteration the objects can be tenured which could lead to more promotions.

Use the concurrent mark sweep garbage collector. This collector is responsible for collecting in old gen and will run in parallel to young gen parallel collector. Its IM ( initial mark ) and RM ( remark ) are the operations that will pause the application. Other times reported in the GC such as CS ( concurrent sweep ) are non-pausing so they won’t really affect your JVM as much as IM and RM.


e.g. -XX:CMSInitiatingOccupancyFraction=85

Assuming you already have UseConcMarkSweepGC, this tells the CMS (Concurrent Mark Sweep Collector) in the old gen to start collection process when old gen is 85% full, if it hasn’t already. Note that CMS could start before old gen reaches 85% even if you have already set the CMSInitiatingOccupancyFraction. CMS has its own logic to decide when to start. If you absolutely wants CMS to start only at 85%, then set also -XX:+UseCMSInitiatingOccupancyOnly. The default is 65%.


Consider using this when you have a big heap or are using large page. It pretouchs and set zero all the pages you have allocated during the initialization of your application. Normally a page is touched when it is used, but in the cases where you have big heap or big page size, this may increase your startup time, but is probably better than doing the pretouch in run time with performance impact.


This will allow CMS to also do some garbage collection in the permanent generation. If you use this option, be sure to also use UseConcMarkSweepGC. This has been seen to solve an apparent perm gen memory leak in Voltron: (described in this page: Perm Gen memory increases)

Leave a comment

Filed under JVM

ParallelRefProcEnabled Option in JVM

Some app uses weak references (say for caching, and it does not mind if JVM gabbage collects these cache lines to “effectively” increase the cache size), then GC spends a lot of time trying to figure which references can be cleaned up. Remark phase is single-threaded  by default unless this option “-XX:+ParallelRefProcEnabled”.

Leave a comment

Filed under JVM