Re: Java performance under a second level VM

2015-04-17 Thread Rob van der Heij
Things may be more clear when you see ttime for the guest on 1st level. I suspect you see the missing cycles there. It's not 2nd level CP doing the hard work but 1st level. Rob -- For LINUX-390 subscribe / signoff / archive

Re: Java performance under a second level VM

2015-04-17 Thread Rob van der Heij
The JIT for example uses polling to sample the state. It sets a timer to pop in a few ms and goes to sleep. But since that state change and timer interrupt reflection isn't in hardware the cost appears excessive. If you would be computing pi second level in Linux it may still be pretty decent. And

Re: Java performance under a second level VM

2015-04-17 Thread Pavelka, Tomas
Hi Rob, thanks for the reply. The performance of Linux under a second level VM always seemed unpredictable to me but after reading your response I started seeing a pattern: whenever I had a poorly performing application on Linux on a second level VM, there was always some kind of networking

Re: Java performance under a second level VM

2015-04-17 Thread Pavelka, Tomas
And because the optimizer uses elapsed time rather than cpu time it keeps recompiling classes and kind of digs is own grave. You might try without the optimizer on 2nd level Linux. I wrote a simple benchmark that just prints a number of lines on the console. Java uses about 180 times more

Re: Java performance under a second level VM

2015-04-17 Thread Rob van der Heij
On Apr 17, 2015 9:40 AM, Pavelka, Tomas tomas.pave...@ca.com wrote: This is probably too specialist topic for general consumption. I find this pretty fascinating, not sure about the others. If no one else replies let's move this offline. Yes me too. But i have that with most exotic

Re: Java performance under a second level VM

2015-04-17 Thread Alan Altmark
On Friday, 04/17/2015 at 02:37 EDT, Pavelka, Tomas tomas.pave...@ca.com wrote: I just want to ensure I am understanding correctly what your are saying: Is it true that waits under software SIE burn CPU where the same waits under hardware SIE do not? That would explain a lot of the performance