Date: Tue, 12 Feb 2013 09:23:50 -0500 From: "David P. Caldwell" <david@code.davidpcaldwell.com> To: freebsd-java@freebsd.org, achill <achill@matrix.gatewaynet.com> Subject: Re: Problem with Java System.exit on OpenJDK 7 Message-ID: <CABBxOK==LSKOKQrqOgSe%2BJbSYzU4xAKatvh9f6LN%2B0TuJt5S7g@mail.gmail.com> In-Reply-To: <CABBxOKncn0yeSSYWtKX7QmhzGK_rRB6a6CeuXnhuj1X_2=GJ_Q@mail.gmail.com> References: <CABBxOKm1zMiXNrU7Nm5ObcFdGb=7KobJfiLqJ4RtzjvrQbKbXA@mail.gmail.com> <1859971.L2l1UW0Dx7@smadev.internal.net> <CABBxOKncn0yeSSYWtKX7QmhzGK_rRB6a6CeuXnhuj1X_2=GJ_Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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 thes= e: > > 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@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 =CE=94=CE=B5=CF=85 11 =CE=A6=CE=B5=CE=B2 2013 17:15:23 David P. Caldw= ell 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 hook= s >> > 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 variabl= es >> > and system properties under which the subprocess is running, and ran i= t >> > 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@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-java >> > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org= " >> - >> Achilleas Mantzios >> IT DEV >> IT DEPT >> _______________________________________________ >> freebsd-java@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-java >> To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org" > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CABBxOK==LSKOKQrqOgSe%2BJbSYzU4xAKatvh9f6LN%2B0TuJt5S7g>