Problem with Java System.exit on OpenJDK 7

[David P. Caldwell]

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"
>>
>>
>>
>