Problem with Java System.exit on OpenJDK 7

[David P. Caldwell]

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"