I am having a problem with Java applications taking of order 20 seconds to start. I am running a fully up-to-date installation of 13.2, 64 bit and have tried both the current java-1_8_0-openjdk packages and the current Oracle JDK (installed into my home directory so as not to interfere with the distribution packages).
Both openjdk and Oracle JDK exhibit the slow start up when a Java application is run in KDE, Gnome or Cinnamon (both with 3D and 2D rendering). However, if I attempt to run one in IceWM it starts almost instantaneously.
I have only seen this problem on openSUSE - I get instantaneous start up in KDE and Mate on Ubuntu.
I believe that this only affects Swing applications as simple console applications start instantly, as does tuxguitar which is built with Eclipse SWT. I have attempted to profile a simple Swing application and it seems to spend almost all of the initial start up time setting the Swing look and feel but I haven’t yet got any deeper to find out what is going on.
The simplest way I have reproduced this is to run jconsole that is installed as part of openjdk. There is a pause of around 20 seconds with no significant CPU or disk activity before the GUI appears. After that it runs as expected.
So it would seem that there is some peculiar to the desktop on openSUSE in some of the environments that is interfering with the Java Swing start up - has anyone else observed this?
You might want to research the heap requirements for your particular Java app(s).
It’s well known for example if you’re running a Java app under particularly heavy load (I run Elasticsearch in my case) it is generally necessary to increase heap allocation. How you do this depends on the Java you are running.
You may also simply be experiencing problems if you don’t have ample amounts of RAM (like 12GB if running KDE). Starting up a Java app can mean very large re-allocation of memory resources initially, particularly if you’ve been doing something else recently that used plenty of memory. To test whether this is the case, you should see a substantial difference starting your Java app soon after bootup (your disk has stopped blinking before you do anything) compared to launching your Java app after hours of doing something else.
Many thanks for the comments. I have experimented a bit with increasing the heap size but it didn’t have any noticeable effect when I tried, also when I have been looking at this I have made sure that my machine was under very light load with the minimum of other applications running. Since I have been investigating the behaviour with different desktop environments my workflow is usually to log out, restart X, log back in and attempt to start a swing app once the the usual log in disk activity has finished.
The application that matters to me is Netbeans but even a test app with a single empty window takes the same 20-ish seconds to bring up the window.
I had semi ruled out the delay being caused by large scale memory shuffling as I see no significant CPU activity during those 20 seconds and very little memory usage change - is there any tell tale sign you would expect to see if the startup process was thrashing memory?
Also, did you really mean 12GB to run KDE? I have 6GB of RAM and frequently have multiple heavy applications open but have never seen anything to suggest that I am getting close to clogging memory. Plus on Ubuntu KDE any Swing app I launch manages to display the GUI without any noticeable delay with the same amount of memory.
All this, plus the observation that tuxguitar (non-Swing as far as I’m aware) brings up its GUI instantly leads me to suspect that something in the openSUSE desktop setup is interfering with the Swing look and feel code.
it doesn’t here. Netbeans brings up its splash screen very fast, and then it loads the main app, which does take some time, but you can see the progress in the splash screen.
I have at times also experienced slow java progs start up. I traced that to some network trouble i.e. the network was down and the program apparently tried to connect to the internet and the network was very slow in answering that it couldn’t. I didn’t investigate any further than that.
Perhaps this can help you.
Does the delay also exist when debugging the app under Netbeans? If so, perhaps you could set a breakpoint in the “main” method and try to find you where the slowdown happens.
Thanks for commenting. Netbeans is quite an interesting case: on other operating systems (and in IceWM on openSUSE) the splash screen appears instantly and straight away the red progress bar starts to advance with associated progress messages. This process takes 5-10s.
On openSUSE in KDE, Gnome etc. the Netbeans splash image appears quickly (although sometimes it is just shown as an empty, solid grey square). After the 20 second delay the progress bar starts to advance and takes 5-10s to load modules etc. and bring up the full GUI. If the splash window was not initially shown correctly it gets rendered correctly as soon as the progress bar starts advancing.
The delay does also occur while debugging - that is the most annoying part about it because it slows down the edit->debug cycle so much. So far I have concentrated on profiling and found that it spends most if not all of the delay time around the look and feel code. I am going to try to dig deeper into that but it gets a bit less pleasant…
The network suggestion is good, but I don’t think it is to blame here: Netbeans has no trouble accessing its update servers etc. and I have no network mounted drives.
Could I ask what desktop environment you run Netbeans in?
The network suggestion got me thinking and I realised that when I tried using IceWM I hadn’t bothered to setup wifi access there so in KDE I tried disconnecting from the internet, opened a Swing app and it started instantaneously.
I searched to see if anyone had suffered a similar problem and found this thread: