<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"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></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>
> On Tue, May 16, 2017 at 1:34 AM, David M. Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> wrote:<br>
</span><span class="">>> Exploding the files out of the JarFile could expose this contention and<br>
>> therefore might be useful as a test - but it would also skew the results<br>
>> a little because you have no decompression overhead, and creating the<br>
>> separate file streams hypothetically might be somewhat more (or less)<br>
>> expensive. I joked about resurrecting jzipfile (which I killed off<br>
>> because it was something like 20% slower at decompressing entries than<br>
>> Jar/ZipFile) but it might be worth considering having our own JAR<br>
>> extractor at some point with a view towards concurrency gains. If we go<br>
>> this route, we could go even further and create an optimized module<br>
>> format, which is an idea I think we've looked at a little bit in the<br>
>> past; there are a few avenues of exploration here which could be<br>
>> interesting.<br>
><br>
> 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't need, like<br>
using read/write locks to manage access and modifications (which we<br>
don'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'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'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'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->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't think that'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'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'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'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>