<div dir="ltr"><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 18, 2017 at 7:50 AM, David M. Lloyd <span dir="ltr">&lt;<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/15/2017 05:21 PM, Stuart Douglas wrote:<br>
&gt; On Tue, May 16, 2017 at 1:34 AM, David M. Lloyd &lt;<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>&gt; wrote:<br>
</span><span class="">&gt;&gt; Exploding the files out of the JarFile could expose this contention and<br>
&gt;&gt; therefore might be useful as a test - but it would also skew the results<br>
&gt;&gt; a little because you have no decompression overhead, and creating the<br>
&gt;&gt; separate file streams hypothetically might be somewhat more (or less)<br>
&gt;&gt; expensive.  I joked about resurrecting jzipfile (which I killed off<br>
&gt;&gt; because it was something like 20% slower at decompressing entries than<br>
&gt;&gt; Jar/ZipFile) but it might be worth considering having our own JAR<br>
&gt;&gt; extractor at some point with a view towards concurrency gains.  If we go<br>
&gt;&gt; this route, we could go even further and create an optimized module<br>
&gt;&gt; format, which is an idea I think we&#39;ve looked at a little bit in the<br>
&gt;&gt; past; there are a few avenues of exploration here which could be<br>
&gt;&gt; interesting.<br>
&gt;<br>
&gt; This could be worth investigating.<br>
<br>
</span>Tomaž did a prototype of using the JDK JAR filesystem to back the<br>
resource loader if it is available; contention did go down but memory<br>
footprint went up, and overall the additional indexing and allocation<br>
ended up slowing down boot a little, unfortunately (though large numbers<br>
of deployments seemed to be faster).  Tomaž can elaborate on his<br>
findings if he wishes.<br>
<br>
I had a look in the JAR FS implementation (and its parent class, the ZIP<br>
FS implementation, which does most of the hard work), and there are a<br>
few things which add overhead and contention that we don&#39;t need, like<br>
using read/write locks to manage access and modifications (which we<br>
don&#39;t need) and (synch-based) indexing structures that might be somewhat<br>
larger than necessary.  They use NIO channels to access the zip data,<br>
which is probably OK, but maybe mapped buffers could be better... or<br>
worse?  They use a synchronized list per JAR file to pool Inflaters;<br>
pooling is a hard thing to do right so maybe there isn&#39;t really any<br>
better option in this case.<br>
<br>
But in any event, I think a custom extractor still might be a reasonable<br>
thing to experiment with.  We could resurrect jzipfile or try a<br>
different approach (maybe see how well mapped buffers work?).  Since<br>
we&#39;re read-only, any indexes we use can be immutable and thus<br>
unsynchronized, and maybe more compact as a result. We can use an<br>
unordered hash table because we generally don&#39;t care about file order<br>
the way that JarFile historically needs to, thus making indexing faster.<br>
  We could save object allocation overhead by using a specialized<br>
object-&gt;int hash table that just records offsets into the index for each<br>
entry.<br>
<br>
If we try mapped buffers, we could share one buffer concurrently by<br>
using only methods that accept an offset, and track offsets<br>
independently.  This would let the OS page cache work for us, especially<br>
for heavily used JARs.  We would be limited to 2GB JAR files, but I<br>
don&#39;t think that&#39;s likely to be a practical problem for us; if it ever<br>
is, we can create a specialized alternative implementation for huge JARs.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:large">​I&#39;m not so sure that the OS page cache will do anything here.  I actually think it would be better if we could open the JAR files using direct I/O, but of course Java doesn&#39;t support that, and that would require native code, so not the greatest option.</div><div class="gmail_default" style="font-size:large"><br></div><div class="gmail_default" style="font-size:large">Andy</div><div class="gmail_default" style="font-size:large">​</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
In Java 9, jimages become an option by way of jlink, which will also be<br>
worth experimenting with (as soon as we&#39;re booting on Java 9).<br>
<br>
Brainstorm other ideas here!<br>
<div class="HOEnZb"><div class="h5">--<br>
- DML<br>
______________________________<wbr>_________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/wildfly-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><font size="4">Andrig (Andy) T. Miller<br></font></div><font size="4">Global Platform Director, Middleware<br></font></div><font size="4">Red Hat, Inc.</font><br></div></div></div></div>
</div></div>