Problem with Java System.exit on OpenJDK 7

[David P. Caldwell]

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