Understanding JVM Performance - It is Fast - Very Fast! JVM code can be just as fast as the equivalent native code. This might come as a shock to some people. Yes - JVM code (like Java or COBOL) can the same speed as native code (like C++ or COBOL). This is generally true. However, in this case I am looking at batch processing, a type of programming which is very common in commercial settings. The nature of traditional batch runs on distributed (non mainframe) hardware means that lots of short run processes are utilised. To demonstrate just how fast JVM programs can be requires overcoming a number of challenges: The Challenges: The first challenge in proving something like this has been the lack of directly comparable languages. As a senior principal developer in the JVM COBOL team at Micro Focus, I am in an almost unique position to compare our battle hardened native COBOL compiler with our soon to be general availability JVM COBOL compiler. The Approach: Javascript comes to the rescue. You can do amazing things with Rhino and JVM COBOL.
C#-VSLP vs J-VSPL, Interesting Stuff Shown Up VSPL - So simple an amoeba can understand it! A Report Of VSPL From C# To Java Gives Some Surprising Results I need a cross platform, easy to use, multi-threaded test system. VSLP has involved into a powerful testing tool, so I just wanted the lastes version in Java rather than C#. The port was really simple. In the port a changes the syntax of VSPL a little, {} replaced [] and : replaced >. I also replaced some of the operator names to make them more consistent (e.g. concat -> $cat). With no optimization, my standard speed test VSPL program produced the following results (green means faster than C# and red means slower - see later for the C# results). But that was not fair so I used JRat (which is really cool - see here to do a little bit of optimization. Now we can see that J-VSPL is running faster in most tests than the C# equivalent. The troublesome tests are marked in pink. Native Binding With JNA The thing I am aiming to test with VSPL is all native C.
JDK: DirectByteBuffers Seem V.Slow On Sun JDK Recently I have been working on the next (GA) release of JVM COBOL from Micro Focus. Hidden away in the guts of part of this system is some JNI. It was using DirectByteBuffers, which are supposed to be the best way to pass blocks of memory from managed to native code. But they are slow! The end of the story is that I found a better way of implementing the functionality which did not require DirectByteBuffers. I am also sure there are situations where they are great. Here is the result: java bbTest Time to 100000 direct byte buffers is: +0000000933 Time to 100000 byte arrays is: +0000000109 That is quite a big difference! Stub + native Method 26.5% 0 + 44 sun.misc.Unsafe.setMemory 21.1% 0 + 35 sun.misc.Unsafe.allocateMemory 9.0% 0 + 15 sun.misc.Unsafe.copyMemory 56.6% 0 + 94 Total stub I went to the source code for DirectByteBuffer and in it we can see the calls to sun.misc.Unsafe.
A High speed variable look up data structure for Java based dynamic languages As part of VSPL I need a way to store variables which is very fast but dynamic. Here is a simple Java implementation. Variables in VSPL (and most lazy, dynamic languages) are represented as Strings and do not have to be declaired before they are used. This is especially so in VSPL where the context in which a variable is used it not known 'up front' due to passing functions and closures around freely at runtime. In the above, the variable 'myVar' gets created twice in two different enclosing contexts. The simple way (as how I did this to start with) is to store variable values in some map which is keyed by the source code's name for the variable. Load the reference to the root node of the tree. We can see that the problems are: We are using multiple objects in key finding and these objects are scattered throughout the memory. A Solution The first realization is that variables do not have to be represented at runtime by the strings by which they are represented in the source.
A canyon size flaw in at the heart of C# and Java. C# and Java are starting to show their age. Here is one example at the most fundamental level of these two languages. Both C# and Java inherit a lot of their syntactic and semantic structure from C. However, they enforce a very different programming paradigm than that in which C is normally written. This forces C# and Java to be asymmetric and flawed in a way which causes constant trouble, considerable performance issues (especially for Java) but which is not seen by most developers due to them not having realised that alternatives exist. Let us first consider C. This is perfect for functions which are quite mathematical in nature. The most common paradigm for managing polyadic returning functions in C is to pass parameters in by reference. Both Java and C# have a build in exception handling system. class A { public MyClass myObject; } class B { public void myObjectFactory(A ret) { ret.myObject=new MyClass(); } }
Tuning The JVM For Unusual Uses - Have Some Tricks Under Your Hat Knowing a little more about the guts of the JVM can make a huge difference, especially if you are coding off the beaten track.Speed counts!I have been working with Java all the way from Java 1.0 whilst I was as post doc' at Zurich University. Back then I used Java to create simple molecular visualisation applet for web-browsers. People often think of Java being compiled to Byte Code and the Byte Code being interpreted. With JIT (hotspot etc.) a common misconception sprung up that some code was just in time compiled whilst the rest was interpreted. The real situation is that all code is interpreted, at least to start with (with one exception - see below). Separating the JVM From Java The Java Virtual Machine (JVM) was designed to work with Java. Traversing The Code Graph In my little example above the effect of not compiling huge methods was much bigger than I originally expected; what is more, the understanding which came from learning why has proved invaluable since! Some final thoughts
COBOL vs JAVA for financial calculations For Financial Calculations COBOL Is Still The Queen Of All Languages - Here Is A Worked Demonstration And Explanation COBOL has evolved in a business centric environment. As the language has developed it has done so to support financial calculations. Financial calculations are either right or wrong, there is no in-between. COBOL handles these notions right in the program syntax. Often, people will say things like "You can just use double precision floating-point. COBOL also has floating-point mathematics. It computes a 25 year investment based on a particular interest rate which is given as the yearly interest rate but actually computed and added to the balance each day. This program below performs the same calculations with both floating-point and exact arithmetic: program-id. When run, using the Micro Focus Visual COBOL IDE... ...this program runs many calculations giving the yield from different starting balances. So, can we take the get-yield-exact COBOL program and port it to Java?
Java On Ubuntu 64 Massively Faster Than Vista 32 Out of curiosity I ran my standard VSPL speed testing in with (the Java implementation) on the same machine in both Ubuntu and Vista (dual boot). Ubuntu was either near the same speed or much faster on each test. To be honest, I was not out to compare the two operating systems; I booted into Ubuntu so I could do some comparisons of other scripting languages to VSPL. Here are the results: The places where it is showing a really big performance gain is where it is processing strings which is the limiting factor. Above is a graph showing the timing differences.
Java Type 'Erasure': What A Pile Of Bollocks One thing which really gets up my nose is giving a complicated sounding name to something simple. Type Erasure is one of the worst examples in IT. Why - because the types ARE NOT ERASED. Don't get me wrong - I am not saying Java Generics is Bollocks. What really happens? Here is a simple example of the use of generics in Java: class Z { static class ZPair<X,Y> { private X _x; private Y _y; public ZPair(X xval,Y yval) { _x=xval; _y=yval; } public X getX() { return _x; } public Y getY() { return _y; } public void setX(X val) { _x=val; } public void setY(Y val) { _y=val; } } public static ZPair<String,Integer> thingy() { return new ZPair<String,Integer>("hi",1); } } If we use javap to just look at the raw declared signatures inside ZPair we do not see any generic information: So does that mean that the generic type information is erased - no! Now we can see that the generic types are defined right in the class file. Is that the exact type of the thingy method I see there? and then run it:
Java Inner Classes - Under The Hood Java inner classes are really clever because they can act as lambda's and closures; but - how do they work under the hood? Well, the truth is that they are implemented using simple engineering rather than some amazing computer science wizardry. Here was have a very simple example of using an inner class to enclose round the value of two private fields in the outer class: There is nothing like looking at what the compiler actually does to get an understanding of how Java and the JVM work. One might be forgiven for thinking this is achieved via features of the JVM. javap -verbose Z Compiled from "Z.java" class Z extends java.lang.Object SourceFile: "Z.java" InnerClass: #23= #4 of #6; //ZPair=class Z$ZPair of class Z minor version: 0 major version: 50 Constant pool: const #1 = Field #6.#43; // Z.aPrivateString:Ljava/lang/String; const #2 = Field #6.#44; // Z.aPrivateInt:I const #3 = Method #22.#45; // java/lang/Object." For completeness, here is the inner class's code.
Java, JVM, JNI and Signal Handling Explained In Simple Terms The Simple Guide To Why JVM 's Raise Signals (deliberately) And What To Do About It! It is time I wrote this up because it is getting boring needing to work this out and explain it over and over again for myself and I am guessing anyone else! If you are using JNI on Linux, Solaris or AIX and get intermittent crashes (especially SIGSEGV or SIGILL) check this out... What Is A Signal - Apart From Really Simple! A *nix (Unix or Linux mainly) operating system has a kernel and processes. The kernel also can raise signals because of instructions passed to it by other software or (often more importantly) because of hardware in the computer detecting 'illegal' actions by processes. The most famous (infamous) signal is SEGV. There are a load of other signals which indicate things like illegal instructions to the CPU all the way down to completely user defined signals. Signal Handlers - The Traditional Approach Some signals can be 'caught' or 'handled' by a process. strace . 613 ! How We Can Fix It? cc -L
JVM/Java: Comparing InvokeDynamic Performance To Invokestatic The reason for invokedynamic is that it is fast. Reflect is very much slower indeed. But is it anything near as fast as invokestatic? This will tell us: This code can answer the question. /** The method which is invoked statically and dynamically */ public static long performCalcLong(long a,long b) { return a + b; } To be fair, I put a invokevirtual in-between the loop and the invokestatic to match the invokevirtual used to access the on-the-fly method which calls invokedynamic. Here are the results: Results! To the question - what is the point of invokedymnamic - it is at least 15 times faster than reflection!