The same application behaves strange in java 10.
In Java 10 CPU usage shows much higher when compared to running in Java 8 or Java 7 even if the GC rate is low.
Raspberry Pi3 Raspberry Pi3 Odroid C2 Odroid XU4
1,20 GHz 1,20 GHz 1,5 GHz 2,0 GHz
Debian 32 Bit SuSE 64 Bit Ubuntu 64 Bit Ubuntu 32 Bit
Start Apache Tomcat 04:30,00 00:29,06 00:27,45 04:08,39
1. page (1. request) 00:50,00 00:03,91 00:03,66 00:24,75
1. page (2. request) 00:03,30 00:00,79 00:00,77 00:02,39
I'm working on an IoT kind of project and needed to test if some web frontend implemented in Java using Tomcat as web server is "fast enough" on our possible hardware. We need to choose between Raspberry Pi3, Odroid C2 and Odroid XU4. Pi3 and C2 both have a 64 Bit CPU with slightly different performance according to their specs, XU4 has a 32 Bit CPU only and should be faster as the other two in theory as well. The important thing is that Pi3 is by default running a 32 Bit OS even if it has a 64 Bit CPU, the XU4 is running 32 Bit as well, but the C2 is running a 64 Bit OS incl. 64 Bit Java etc.
Comparing all those devices in default settings we found that the C2 was significantly faster than the other both. It was 4+ minutes vs. ~30 seconds for a restart of Tomcat with some test application of ours. Additionally, tools like htop showed that most of the runtime all cores of the C2 were used, whereas Pi3 and XU4 were mostly only able to put one core under load. That great performance difference was the same after Tomcat has loaded and we were able to browse through our test app: It was ~1,5 seconds vs. 4 to 5,5 seconds for just browsing some page with some CSS/JS.
While the default OS for the Pi3 is 32 Bit only, we were able to successfully install a special 64 Bit SuSE distribution. And guess what happened? The performance was much closer now to what we saw on the C2 already, almost the same for many tests, even though the Pi3 is clocked at only 1,2 vs. 1,5 GHz of the C2. Especially interesting was that now all cores of the Pi3 were under load most of the time as well, so overall behaviour was very much like the C2 now.
So by only switching to 64 Bit OS, Java etc. we saw that dramatically improvement in performance. Everything else was the same, same test app, Tomcat etc., nothing overclocked, no other storage or else. How can that be? What is responsible for that dramatic improvement?
With a 64 Bit OS we see that all cores of the devices are more under load compared to 32 Bit. But why should the Linux kernel scheduler care about if it's running on 32 or 64 Bit this much?
And if it doesn't and the difference comes from Java, why/how that? Shouldn't a 32 Bit and 64 Bit JVM perform almost identically in such a simple test? Shouldn't both especially put almost the same load on cores and not behave that different? The architecture of the OS shouldn't have any effect on how many threads are used inside the JVM, that is mostly under control of Tomcat and our test app and therefore didn't change. According to what I've read about performance of 32 vs. 64 Bit Java, the difference should be negligible in my use case. Additionally, other users with a better performance of a 64 Bit JVM don't seem to have a factor of 4 to 5 like I'm seeing and the differences on CPU load of individual cores aren't explained as well.
Our test is not I/O bound, we don't allocate much memory or work with many threads or such, it's almost strictly CPU, only compiling Java classes and publishing HTML, CSS and JS. But we see very different load on the cores depending on 32/64 Bit and very different performance results.
One of my colleagues said he read somewhere that Java is internally working with 64 Bit values only and that therefore on a 32 Bit CPU/OS more cycles are needed to process the same thing. I guess his source doesn't mean really everything, but only references/pointers to memory like for objects. But I can't believe that a 32 Bit JVM is internally really using 64 Bit pointers for no reason, especially if even optimizations like compressed oops exist. But might be an explanation, so any ideas on that?
If it's of any interest, the packages on the 32 Bit OS all had "armhf" as architecture, compared to "arm64" on the 64 Bit ones. I thought that might have influence on how Java was built, maybe really using 64 Bit pointers for some weird reason?
Java was OpenJDK 8 always, same architecture like OS and as current as the package manager of the OS provides. Pi3 with SuSE had 1.8_144, UB provided 1.8_131 for both 32 Bit and 64 Bit installations, all were server VMs. Additionally, the Linux Kernel was different e.g. Pi3 with SuSE vs. C2 and XU 4 with UB: Pi3 had some current 4.x, C2 some old 3.14 and XU 4 some current 4.9 as well.
So, any ideas on where the difference comes from? Thanks!
You've told you installed OpenJDK 8 from the standard package.
There has never been an optimized build of OpenJDK 8 for ARM 32 (at least on Debian and Ubuntu). The default package is built from "Zero" port which does not even have a JIT compiler.
root#localhost:~# java -server -version
openjdk version "1.8.0_131"
OpenJDK Runtime Environment (build 1.8.0_131-8u131-b11-1~bpo8+1-b11)
OpenJDK Zero VM (build 25.131-b11, interpreted mode)
^^^^^^^ ^^^^^^^^^^^^^^^^
Try to install Oracle JDK manually from Java SE downloads page.
It has an optimized HotSpot JVM inside. And it indeed works much faster.
root#localhost:~# /usr/java/jdk1.8.0_131/bin/java -server -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) Server VM (build 25.131-b11, mixed mode)
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^
On the contrast, Aarch64 port of HotSpot JVM has been a part of OpenJDK for a long time. So, on a 64-bit OS the default OpenJDK package comes with HotSpot JVM that includes an optimizing JIT compiler.
We have a set of Java applications that we have been developing for years that are launched remotely via Web Start. After updating to Java SE 8 Update 91 there is a very significant pause (20-60 seconds depending on the application) in the startup process with no indication to the typical user that anything is happening. This pause occurs after Java's "Starting Application" dialog closes and before the application is launched.
The length of the pause appears to be correlated with the size of the application. Reverting to Java 8 Update 77 eliminates the pause altogether, and these same applications start without any pause.
Our applications do request "all-permissions" as we need to read/write data to the client's drive for caching purposes. So all of our jars are signed and have the necessary manifest modifications.
If your Java settings have the Java console enabled then the console is displayed immediately following Java's "Starting Application" dialog that appears when the application's JNLP file is accessed. However, no activity is seen in the console during this pause (for instance none of the typical Java class loading messages appear until after the pause and none of our code in the "main" method is executed until after the pause).
Some of these applications are fairly large. The code we've written is about 10-12MB, and additional resources total between 15-20MB depending on the application.
I found a JDK bug report that sounds very similar... bug report
This report states that using an older Java version results in instant startup if the Java cache is removed before the first start. The issue that I'm reporting does not seem to be impacted by the Java cache. Reverting to Java 8 Update 77 results in instant startup without deleting the Java cache.
The Java release notes for Java 8 Update 91 mention a bug fix "Regression in Applet startup time fixed". But I don't see anything that would indicate an intentional change that would result in a long pause during startup (such as increased security scanning, etc).
With this length of pause in startup and no ability to indicate to the user that something is happening we are getting complaints about the applications.
Any help would be greatly appreciated.
UPDATE July 1, 2016...
I found this SO question that seems to describe the identical symptoms: similar issue. However, it was related to Java 7 Update 40. And the resolution was to disable the revocation check in the deployment.properties file.
I have used the Java console to set "Do not check" for both "Perform signed code certificate revocation checks on" and "Perform TLS certificate revocation checks on". And I checked to make sure that the changes are reflected in the deployment.properties file. However, these setting do not fix or improve the issue at all.
If this had worked it would be a great indicator of the problem, but it would not be a useful "solution" to have clients turn off these revocation checks in their advanced settings. It especially wouldn't be helpful for the general public that have access to a number of our applications.
UPDATE July 7, 2016...
Based on the comment by jaivalis I downloaded the early access release of the Java 8 Update 112 JRE. When I run our applications with this JRE there is no pause at all. The applications run immediately after the "Starting Application" dialog closes.
So far I can't find any notes that explain why this would be. I am hoping this "fix" isn't the result of new security measures that have not been completely applied to this early access release. I'm hoping that something has actually been addressed and that the immediate launch performance will remain when this release is official.
By the way I cannot find an official release date for Java 8 Update 112. I was hoping it would happen in July, but I see some indications of October. Anyone have any information on when this update will be generally available?
Here is the early access page for Java 8 Update 112 early access
Here is the release date info I found Java 8 Update 112 release timeline
This page also mentions a Java 8 Update 102, but I can't find an early access release for that update. Any links I find point to the 112 update.
This issue has been resolved with the Java 8 update 101 release (technically build 1.8.0_101-b13).
Hello I found something that might help you :)
In the recent patch notes from Oracle it stated that this was a bug issue in the last patch of Java
Personally I would find a third-party to download a previous version of java
Here is a link to the patch notes
http://www.oracle.com/technetwork/java/javase/8u20-relnotes-2257729.html
Hope you find the issue!
Good morning all,
I have been tasked with investigating a possible rollout of Java 8. Ideally I do not want this out on PC's in my enterprise but I may have no option. A lot of testing needs to be done.
Our current version is Java 7 Update 67, and I successfully deployed Java and using an MST, I disabled the Java AutoUpdate feature, which gets rid of the unwanted prompt "Your Java Version is Out Of Date - Select Update, Block, Later"
I have tried applying the same config to my Java 8 MST, although some of the switch names that control the auto update have changed to the Java v7 MST, the theory should work the same. The MST is applying and I can see my changes, yet I am still prompted with the "Your Java version is out of date"
I have looked up numerous sites that have dealt with Java 8 deployment, yet I still cannot get it to work.
I can't see where I can attach my MST, but I have the switches applied below
Any help will be much appreciated
Cheers
Larry
AUTO_UPDATE = 0
EULA=0
JU 0
REBOOT 0
STATIC 0
WEB_ANALYTICS 0
[Changed properties]
AUTOUPDATECHECK 0
JAVAUPDATE 0
[New registry entries]
a_notifyreg 2 SOFTWARE\JavaSoft\Java Update\Policy NotifyDownload #0 jz
a_updatereg 2 SOFTWARE\JavaSoft\Java Update\Policy EnableJavaUpdate #0 jz
a_updatereg0 2 SOFTWARE\JavaSoft\Java Update\Policy EnableAutoUpdateCheck #0 jz
I'm developing a JavaFX desktop application using Java 7. The application I'm developing uses 10-12 background threads which gets system information or makes HTTP request. I also use some JNA and JNI code.
When i limit the heap size to 40 MB, it's fairly enough and the application runs without a problem with total ~100 MB memory.
However since Oracle is dropping support for Java 7 in April, I decided to upgrade the application to Java 8, the upgrade went smoothly, not much code change required, but i noticed the total memory consumption increased to 130+-20 MB. I researched about this problem, and found out Java 8 introduced Metaspace, I think that may be the problem, but in Java 7 I never set the PermGenSize so in the end I have no idea why the application uses more memory.
Just so you know Metaspace usage is about 33-36 MB in VisualVM.
Any help would be appreciated , thanks
-------SOLVED---------
The problem was; the JDK I was using was 64 bit, since 64 bit JDK on Windows only contains server mode, I installed a 32 bit JDK 8 and started using it in client mode, since then the RAM usage is about 80 MB.