Problem with Java System.exit on OpenJDK 7

Achilleas Mantzios achill at matrix.gatewaynet.com
Tue Feb 12 14:54:59 UTC 2013


If you haven't cleaned the sources yet, why don't you look at the specific implementations 
of System.exit() in opnjdk 7 vs openjdk 6, in /usr/ports/java ?

On Τρι 12 Φεβ 2013 09:49:38 you wrote:

One additional insight: the problem exists in openjdk7, but not openjdk6.



On Tue, Feb 12, 2013 at 9:23 AM, David P. Caldwell <david at code.davidpcaldwell.com> wrote:

It appears whatever is happening is happening within the halt0 native method inside java.lang.Shutdown. If I replace Shutdown with my own version and prepend it to the bootclasspath, the statement prior to the invocation of halt0 executes before the delay begins. Still no idea what lock the program is trying to acquire. I'm going to try to learn and use gdb and see if it reveals anything, so first I'm building a debug version of the port. 



On Tue, Feb 12, 2013 at 5:27 AM, David P. Caldwell <david at code.davidpcaldwell.com> wrote:

Well, I wasn't familiar with a lot of kernel debugging tools before, but I'm catching up.


Ironically, this now appears related to the issue just discussed on this list a few days ago. I'm sure this will sound familiar to everyone. My ktrace from the relevant part of execution contains a huge number of these: 


 26795 java     1.808597 CALL  _umtx_op(0x2831e068,0xf,0,0,0xbf7a9870)
 26795 java     1.838640 RET   _umtx_op -1 errno 60 Operation timed out


A bit of web searching reveals that this probably is related to libthr, but I am pretty green in this area (I mostly stay way above the system libraries in my day-to-day work), so I'm not quite sure how to interpret it or what to do next. I can't even figure out where errno values for _umtx_op are documented, nor do I have any idea how to figure out what the VM is *actually* trying to do in this section. 


Any pointers or tips?



On Tue, Feb 12, 2013 at 2:46 AM, Achilleas Mantzios <achill at smadev.internal.net> wrote:

some suggestions/thoughts :
- ktrace
- truss
- gdb against a _g version (debugging enabled) of OpenJDK 7 java (if available)
- jdb

I doubt KDE or anything would have any relation to your problem.
It might more likely be related to libthr/libc

What version of Java do you have on Windows?
You have to realize jumping from Windows/(Oracle?)Java to FreeBSD/Openjdk7 makes
a huge difference.

Hmmmm this looks also like a TCP/IP timeout kind of thing... just a raw speculation.
Can you try with disabling IPV6?


On Δευ 11 Φεβ 2013 17:15:23 David P. Caldwell wrote:
> So I'm having a problem with the performance of a Java subprocess running
> under Java, running on 9.0-RELEASE i386.
>
> It's a big subprocess, difficult to decompose. It's a big parent process,
> difficult to decompose. I'm working on it. I've nearly ruled out the parent
> process as the culprit (see below), but I include it for completeness, just
> in case there's something I'm missing.
>
> Everything runs as expected on Windows, which brings me here to this list.
>
> Basically, the parent process launches the subprocess using a Java command.
> It runs. It runs fine. The *subprocess* calls System.exit(0). That's where
> the weirdness begins.
>
> System.exit(), for this program, takes about 2.6 seconds to run. And I
> can't figure out why. It takes 0.025 seconds on Windows.
>
> The program is a command shell, essentially, so having every subshell add
> 2.6 seconds of unnecessary execution time really slows things down.
>
> 1. The application has System.runFinalizersOnExit set to false; I checked
> in java.lang.Shutdown using reflection to be sure.
>
> 2. The application, during its shutdown, has only one shutdown hook to run
> -- the application shutdown hooks hook. That application shutdown hooks
> hook has one hook, registered by me, which prints the timestamp (for trying
> to debug this), only. Something takes 2.6 seconds to end the VM after this.
>
> 3. There are no temporary files to delete; I checked in
> java.io.DeleteFilesOnExit using reflection to make sure. The system
> registered shutdown hook in the slot for DeleteFilesOnExit is null.
>
> The problem appears to have nothing to do with the parent process. I
> synthesized a giant command line command using the environment variables
> and system properties under which the subprocess is running, and ran it
> from the bash prompt, and still got the 2.6 second delay, based on running
> the program inside a bash wrapper that first ran the subprocess giant
> command, then printed the system time. I'm 99.9% ready to rule it out based
> on that.
>
> During one experiment, when running the program twice on the same command
> line, one of the runs, using the same command line, actually completed
> System.exit in a time I'd expect -- about 0.03 seconds. The other took
> about 2.6 seconds. All subsequent runs have take about two-and-a-half
> seconds after the shutdown hooks; I haven't been able to reproduce the
> success and I am quite sure I didn't change anything.
>
> I'm running this in a graphical terminal on KDE; haven't tried from an
> ordinary console (obviously I am gradually broadening the things I'm doing,
> so I'll probably get to that). The program is not graphical and presents no
> GUI.
>
> The application does reference the standard input stream but the particular
> program I was running consumes no input. It references stdout and stderr as
> well, and is emitting output to those consoles.
>
> Does anyone have any idea or suggestions about where I should be looking at
> this point? Obviously it's hard to instrument the program further on
> FreeBSD -- I assume the NetBeans Profiler / jvisualvm stuff does not work
> on FreeBSD; that's the last I heard.

> _______________________________________________
> freebsd-java at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-java
> To unsubscribe, send any mail to "freebsd-java-unsubscribe at freebsd.org"
-
Achilleas Mantzios
IT DEV
IT DEPT
_______________________________________________
freebsd-java at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-java
To unsubscribe, send any mail to "freebsd-java-unsubscribe at freebsd.org"









-
Achilleas Mantzios
IT DEV
IT DEPT
Dynacom Tankers Mgmt


More information about the freebsd-java mailing list