<br><font size=2 face="sans-serif">Thanks you for your suggestion. &nbsp;Yes,
we real-time Java has been considered. Unfortunately, it is not supported
on our SUSE 10 64 bit Itanium chip set. &nbsp;I've had a series of email
exchanges with Gregory Bollella. &nbsp;If even a fraction of the claims
are true, we would be very interested when the time comes to change our
machines over to a x86 chip set.</font>
<br>
<br><font size=2 face="sans-serif">Thanks again,</font>
<br>
<br><font size=2 face="sans-serif"><br>
Mark Maxey<br>
Raytheon, Garland<br>
580/2/P22-1<br>
(972)205-5760<br>
Mark_R_Maxey@Raytheon.com</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>John Pampuch &lt;john.pampuch@sun.com&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: John.C.Pampuch@sun.com</font>
<p><font size=1 face="sans-serif">04/14/2009 05:19 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Paul Hohensee &lt;Paul.Hohensee@sun.com&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Mark R Maxey &lt;Mark_R_Maxey@raytheon.com&gt;,
hotspot-gc-dev@openjdk.java.net, Andrew M Dungan &lt;Andrew_M_Dungan@raytheon.com&gt;,
&quot;Y. Srinivas Ramakrishna&quot; &lt;Y.S.Ramakrishna@sun.com&gt;, David
A Lilly &lt;David_A_Lilly@raytheon.com&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: Garbage Collection Pauses &amp;
Non-interruptable System Calls</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=3 face="Arial">Mark-<br>
<br>
You've probably already gotten this suggestion, but another alternative
to look at is Sun's real-time system.<br>
</font><font size=3 color=blue face="Arial"><u><br>
</u></font><a href=http://java.sun.com/javase/technologies/realtime/index.jsp><font size=3 color=blue face="Arial"><u>http://java.sun.com/javase/technologies/realtime/index.jsp</u></font></a><font size=3 face="Arial"><br>
<br>
Right now, we offer a Java 5 compatible release that provides a number
of means of managing the impact of GC in an application. &nbsp;It does
trade off throughput, but that may not be a barrier in your specific case.
&nbsp;It also provides a threading model with fine grained priorities that
may be more to your liking &nbsp;It offers a priority inversion protocol
as part of the implementation too.<br>
<br>
-John</font><font size=3><br>
<br>
Paul Hohensee wrote: </font>
<br><font size=3>The url for &quot;Hotspot Runtime Overview of JNI&quot;
didn't come through for me. <br>
<br>
In any case, as Ramki noted, Hotspot lets native code called from Java
run free <br>
during GC pauses, unless said native code calls back into the jvm for some
reason, <br>
including just returning back to Java from native. &nbsp;Hotspot does _not_
try to <br>
pause threads executing native code, nor does Hotspot use signal mechanisms
<br>
to block threads executing Java code so GC can happen. &nbsp;Hotspot uses
a polling <br>
mechanism instead because signal delivery mechanisms on Unix and Linux
are <br>
unreliable. &nbsp;I doubt you'll be able to reproduce the JRockit issue
with Hotspot. <br>
You might have other problems, but not that one. <br>
<br>
I suggest forwarding your questions to the JRockit team at Oracle. &nbsp;Though
I suspect <br>
some of them are on this list too. :) <br>
<br>
Please try Hotspot before you give up on Java. &nbsp;From your description,
you should <br>
use the CMS (concurrent mark-sweep) collector. &nbsp;See also the GC performance
info <br>
accessible from <br>
</font><font size=3 color=blue><u><br>
</u></font><a href=http://java.sun.com/performance><font size=3 color=blue><u>http://java.sun.com/performance</u></font></a><font size=3>
<br>
<br>
and Jon Masamitsu's blog <br>
</font><font size=3 color=blue><u><br>
</u></font><a href=http://blogs.sun.com/jonthecollector/><font size=3 color=blue><u>http://blogs.sun.com/jonthecollector/</u></font></a><font size=3>
<br>
<br>
Paul <br>
<br>
Mark R Maxey wrote: </font>
<br><font size=3><br>
After reading the last paragraph of HotSpot Runtime Overview of JNI more
closely, I understand more. &nbsp;I think we're almost on the same page.
&nbsp;The problem seems to be that all threads are suspended until the
Java thread returns from the native call. <br>
<br>
<br>
Mark Maxey <br>
Raytheon, Garland <br>
580/2/P22-1 <br>
(972)205-5760 </font><font size=3 color=blue><u><br>
</u></font><a href=mailto:Mark_R_Maxey@Raytheon.com><font size=3 color=blue><u>Mark_R_Maxey@Raytheon.com</u></font></a><font size=3>
<br>
<br>
<br>
*Mark R Maxey/US/Raytheon* <br>
<br>
04/14/2009 12:37 PM <br>
<br>
 &nbsp; &nbsp; <br>
To <br>
 &nbsp; &nbsp;&quot;Y. Srinivas Ramakrishna&quot; </font><a href=mailto:Y.S.Ramakrishna@Sun.COM><font size=3 color=blue><u>&lt;Y.S.Ramakrishna@Sun.COM&gt;</u></font></a><font size=3>
<br>
cc <br>
 &nbsp; &nbsp;</font><a href="mailto:hotspot-gc-dev@openjdk.java.net"><font size=3 color=blue><u>hotspot-gc-dev@openjdk.java.net</u></font></a><font size=3>,
</font><a href=mailto:Y.S.Ramakrishna@Sun.COM><font size=3 color=blue><u>Y.S.Ramakrishna@Sun.COM</u></font></a><font size=3>,
Andrew M Dungan/US/Raytheon@MAIL, David A Lilly/RCS/Raytheon/US@MAIL, Mark
R Maxey/US/Raytheon@MAIL <br>
Subject <br>
 &nbsp; &nbsp;Re: Garbage Collection Pauses &amp; Non-interruptable System
CallsLink &lt;Notes://MK2-MSG05/86256EF3005F851B/38D46BF5E8F08834852564B500129B2C/E1F59319D41C5C4886257598005422BD&gt;
<br>
<br>
<br>
<br>
 &nbsp; &nbsp; <br>
<br>
<br>
<br>
<br>
Thank you for your reply. &nbsp;The speed and depth of your response is
encouraging. <br>
<br>
Let me confess something I should have done up-front. &nbsp;The behavior
we're seeing is using JDK 5 via JRockit R27.6. &nbsp;We're in the process
of reproducing these problems under HotSpot JDK 6 Update 12, though it'll
be a few days before we can do so. &nbsp;The reason I'm pinging this forum
is to research in advance what differences we might expect between the
two JVMs. <br>
<br>
Let me describe exactly what we're seeing as provided by doing an strace
on the process: <br>
<br>
 &nbsp; 1. A Java thread calls a native C code that ultimately calls a
<br>
 &nbsp; &nbsp; &nbsp;pwrite(). &nbsp;We suspect that the device driver
ultimately makes a <br>
 &nbsp; &nbsp; &nbsp;non-interruptable system call to transfer the data
directly from <br>
 &nbsp; &nbsp; &nbsp;our mem-aligned 128 MB buffer to disk. <br>
 &nbsp; 2. The GC thread sends a tgkill(SIGUSR1) to all threads <br>
 &nbsp; 3. The GC thread waits on mutex #1 (presumably waiting on all the
<br>
 &nbsp; &nbsp; &nbsp;threads to signal it that it can begin GC) <br>
 &nbsp; 4. The Java thread wakes mutex #1 (presumably signaling the GC
it <br>
 &nbsp; &nbsp; &nbsp;is ready to go) <br>
 &nbsp; 5. The Java thread waits on mutex #2 (presumably waiting on GC
to <br>
 &nbsp; &nbsp; &nbsp;finish) <br>
 &nbsp; 6. The GC thread wakes mutex #2 (presumably telling the Java thread
<br>
 &nbsp; &nbsp; &nbsp;it can resume processing) <br>
<br>
<br>
We're seeing times between #3 &amp; #4 that are proportional to the amount
of time spent in the pwrite(). &nbsp;We also see some overhead between
#5 &amp;#6 that is proportional to the number of Java threads we have (currently
between 30 &amp; 40 that we've created not counting the JVMs). <br>
<br>
Unfortunately, the JRockit logging only reveals the actual time GC takes
(#4 - #5). &nbsp;Hopefully, HotSpot's logging includes the total time (#2
- #6). <br>
<br>
I'm pursuing these questions with Oracle/BEA. &nbsp;Again, I'm just trying
get a feel for HotSpot's behavior in comparison. &nbsp;While we're using
JRockit today, HotSpot will be our ultimate platform. <br>
<br>
<br>
One alternate solution that has been suggested is infrequently calling
GC explicitly within our code during special times when we know we can
afford to take the hit. &nbsp;We would even accept a greater hit than normal
if we could avoid being impacted during critical times. &nbsp; Everything
I've ever read says to not do this, but I'm curious why in this case this
is a bad idea. &nbsp;Note that we're using the concurrent GC, so I'm not
even sure if System.gc() supports this. <br>
<br>
<br>
Thanks again! <br>
<br>
<br>
Mark Maxey <br>
Raytheon, Garland <br>
580/2/P22-1 <br>
(972)205-5760 </font><font size=3 color=blue><u><br>
</u></font><a href=mailto:Mark_R_Maxey@Raytheon.com><font size=3 color=blue><u>Mark_R_Maxey@Raytheon.com</u></font></a><font size=3>
<br>
<br>
<br>
*&quot;Y. Srinivas Ramakrishna&quot; </font><a href=mailto:Y.S.Ramakrishna@Sun.COM><font size=3 color=blue><u>&lt;Y.S.Ramakrishna@Sun.COM&gt;</u></font></a><font size=3>*
<br>
Sent by: </font><a href=mailto:Y.S.Ramakrishna@Sun.COM><font size=3 color=blue><u>Y.S.Ramakrishna@Sun.COM</u></font></a><font size=3>
<br>
<br>
04/14/2009 10:19 AM <br>
<br>
 &nbsp; &nbsp; <br>
To <br>
 &nbsp; &nbsp;Mark R Maxey </font><a href=mailto:Mark_R_Maxey@raytheon.com><font size=3 color=blue><u>&lt;Mark_R_Maxey@raytheon.com&gt;</u></font></a><font size=3>
<br>
cc <br>
 &nbsp; &nbsp;</font><a href="mailto:hotspot-gc-dev@openjdk.java.net"><font size=3 color=blue><u>hotspot-gc-dev@openjdk.java.net</u></font></a><font size=3>
<br>
Subject <br>
 &nbsp; &nbsp;Re: Garbage Collection Pauses &amp; Non-interruptable System
Calls <br>
<br>
<br>
<br>
 &nbsp; &nbsp; <br>
<br>
<br>
<br>
<br>
<br>
Hello Mark -- <br>
<br>
I am assuming your threads doing DMA are actually executing native code
(or <br>
waiting for signals in native code). &nbsp;Threads in native code do not
need to <br>
synchronize \in any manner with GC while they are executing native code.
<br>
It is only the transitions to and from native mode (from Java code) that
<br>
require <br>
synchronization. Roughly speaking, the JVM fences off those native <br>
threads so that, in the event that they need to re-enter the JVM or <br>
access the Java heap, they will be suspended until a GC/safepoint that
<br>
is in progress is completed. <br>
<br>
Thus, I do not believe you need to fear that a long-running DMA call would
<br>
cause GC's to be delayed (which I understand is your &nbsp;main concern
below). <br>
<br>
Have you actually seen cases where this is happening? If so, what <br>
version of the JDK <br>
are you running? <br>
<br>
thanks. <br>
-- ramki <br>
<br>
Mark R Maxey wrote: <br>
&gt; Hello, <br>
&gt; <br>
&gt; I have a problem I was hoping with which I need some advice. <br>
&gt; <br>
&gt; We wrote a custom JNI library for file I/O that sits underneath the
Java <br>
&gt; NIO FileChannel. &nbsp;One of our driving requirements is highly performant
<br>
&gt; file I/O. &nbsp;We achieved this by doing DMA I/O from large direct
memory <br>
&gt; aligned buffers. &nbsp;The JNI is very trivial - it just takes a buffer
and <br>
&gt; performs the appropriate system call based on the parameters given
to it. <br>
&gt; 100% of the logic for calculating offsets, buffer management, etc.
is all <br>
&gt; in our implementation of java.nio.FileChannel. <br>
&gt; <br>
&gt; Here's our problem: &nbsp;We have requirements to respond to some
messages in <br>
&gt; as little as 250 ms. &nbsp;During this time, we're doing file writes
of 128 MB <br>
&gt; that take around 200 ms. &nbsp;When GC kicks in, it tries to pause
all threads. <br>
&gt; &nbsp;Because the DMA write is non-interruptable, GC waits for the
I/O to <br>
&gt; complete before being able to pause the thread &amp; run. &nbsp;That
means that GC <br>
&gt; can take well over 200 ms putting us in grave danger of missing our
<br>
&gt; timelines. &nbsp;Worse, there is always the chance the write will
hang due to a <br>
&gt; bad filesystem. &nbsp; We've seen this cause the JVM to hang indefinitely
<br>
&gt; forcing us to cycle the process. <br>
&gt; <br>
&gt; Unless we find a solution that allows GC to continue while doing this
I/O, <br>
&gt; we will convert all the code to C++. &nbsp;While that might solve
our timeline <br>
&gt; for that particular process, we have many less performance critical
<br>
&gt; processes that use our JNI FileChannel libraries that would hang if
a <br>
&gt; filesystem goes bad. <br>
&gt; <br>
&gt; We've tweaked the file system device timeouts down to a minimum, but
they <br>
&gt; are still very high (on the order of several seconds to minutes).
&nbsp;It <br>
&gt; would be nice if the JVM had a similar timeout for pausing threads,
i.e., <br>
&gt; where the pause times out after X number of milliseconds. &nbsp;We'd
be willing <br>
&gt; to sacrifice a larger heap size and postpone GC in the hopes that
the next <br>
&gt; time it ran GC, we wouldn't be in the middle of a non-interruptable
system <br>
&gt; call. <br>
&gt; <br>
&gt; The only solution being batted around here is pushing the system calls
out <br>
&gt; of Java threads and into native threads. &nbsp;The JNI call would
push the info <br>
&gt; for the I/O call onto a native C++ queue where a small number of native
<br>
&gt; threads (3?) would pull the data off the queue and perform the actual
<br>
&gt; system call. &nbsp; The trick is finding an implementation where the
Java <br>
&gt; thread blocked waiting on a response from the native thread is <br>
&gt; interruptible. &nbsp;All this assumes GC doesn't try to pause native
threads. <br>
&gt; We thought about using pthreads, but were concerned about its signal
<br>
&gt; interaction with the JVM. &nbsp;So, we're leaning towards using pipes
to push <br>
&gt; data from one thread to another. <br>
&gt; <br>
&gt; If you have any suggestions or advice, we are desperate for your wisdom.
<br>
&gt; <br>
&gt; Thanks! <br>
&gt; <br>
&gt; <br>
&gt; Mark Maxey <br>
&gt; Raytheon, Garland <br>
&gt; 580/2/P22-1 <br>
&gt; (972)205-5760 <br>
&gt; </font><a href=mailto:Mark_R_Maxey@Raytheon.com><font size=3 color=blue><u>Mark_R_Maxey@Raytheon.com</u></font></a><font size=3>
<br>
&gt; <br>
&gt; &nbsp;<br>
<br>
<br>
<br>
</font>
<br>
<br>
<br>