Date: Tue, 12 Feb 2013 09:49:38 -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: <CABBxOKnQNyCcHpMdg4D=C4YRws1GtS4wXbRC_eL2w_-3PJBiAw@mail.gmail.com> In-Reply-To: <CABBxOK==LSKOKQrqOgSe%2BJbSYzU4xAKatvh9f6LN%2B0TuJt5S7g@mail.gmail.com> References: <CABBxOKm1zMiXNrU7Nm5ObcFdGb=7KobJfiLqJ4RtzjvrQbKbXA@mail.gmail.com> <1859971.L2l1UW0Dx7@smadev.internal.net> <CABBxOKncn0yeSSYWtKX7QmhzGK_rRB6a6CeuXnhuj1X_2=GJ_Q@mail.gmail.com> <CABBxOK==LSKOKQrqOgSe%2BJbSYzU4xAKatvh9f6LN%2B0TuJt5S7g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
One additional insight: the problem exists in openjdk7, but not openjdk6. On Tue, Feb 12, 2013 at 9:23 AM, David P. Caldwell < david@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 versi= on > and prepend it to the bootclasspath, the statement prior to the invocatio= n > 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 s= ee > 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 the= se: >> >> 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. Cald= well 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 t= o >>> run >>> > -- the application shutdown hooks hook. That application shutdown hoo= ks >>> > 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 complete= d >>> > System.exit in a time I'd expect -- about 0.03 seconds. The other too= k >>> > 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 th= e >>> > 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 a= n >>> > 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.or= g >>> " >>> - >>> 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?CABBxOKnQNyCcHpMdg4D=C4YRws1GtS4wXbRC_eL2w_-3PJBiAw>