Tried looking at LogCompilation output with jitwatch? It's been helpful for me in the past to understand why something wouldn't get jitted.
Todd On Mon, Feb 4, 2019, 7:54 PM Shevek <[email protected] wrote: > Update: I now think this is slow (but not AS slow) on the Core i7-5600U > so this may be a regression from _181 to _191, and not entirely > CPU-dependent? > > Wrapping the two static methods in an otherwise-pointless class, and > calling them as instance methods made the code much faster. > > Is it relevant that the class in question is 522419 Kb in size and > contains 1696 (mostly instance) methods? No individual method in it is > larger than 8K, so they all JIT. > > The outer readVarintTable method is called about 100K-500K times, so > there's plenty of chance to replace it. > > No synchronization is used. > > I'm still in "WAT?" territory. > > S. > > On 2/4/19 6:26 PM, Shevek wrote: > > Hi, > > > > I have a very simple routine which, on some JVMs/systems, which I have > > not yet entirely narrowed down, suffers a 50x slowdown. The code is > > included below. > > > > In perf-java-flames, I see: > > > > <clinit> -> readVarintTable (90%), of which: > > readVarintTable -> readVarint (4%) > > readVarintTable -> resolve_static_call -> libjvm.so (86%) <-- THE WAT? > > > > So what is a perfectly trivial method doing spending 90% of it's time > > inside resolve_static_call? What's going on? > > > > My google searches turned up a note to do with loop unrolling and some > > optimizations breaking for static methods, so I will try this with > > non-static methods. > > > > Slow on openjdk 1.8.0_191, Xeon E-2176M (Lenovo P1 laptop, 12-thread) > > Fast on openjdk 1.8.0_191, Core i7-5600U (Lenovo T550 laptop, 4-thread) > > I think Fast on Xeon E5620 (Supermicro rack, 8 thread). > > I think Slow on AMD Epyc 7301 16-core, 64-thread. Will investigate more. > > > > Knocking off the obvious: > > * It's not doing meaningful amounts of allocation, and no GC. > > * Total data size is 100M-1G. > > * Both machines running same code, same dataset, ... > > * This is single-threaded, and runs early in the JVM startup. > > * It's doing I/O over JAR-resource -> BufferedInputStream -> > > DataInputStream but it's not I/O contended, based on the calls in the > > flamegraph. > > > > But I feel that a 50x slowdown in an unexplained native call because of > > ... what, the number of cores ... bears some explanation. I can post the > > flamegraphs if that helps. > > > > And here is the code, which is as boring as anything, so what gives: > > > > > > /** Reads a little-endian varint with no optimization for negative > > numbers. */ > > private static int readVarint(@Nonnull DataInputStream in) throws > > IOException { > > int result = 0; > > for (int shift = 0; shift < 32; shift += 7) { > > int b = in.read(); > > if (b == -1) > > throw new EOFException("Truncated varint in stream."); > > result |= (b & 0x7f) << shift; > > if ((b & 0x80) == 0) > > return result; > > } > > throw new IOException("Malformed varint in stream."); > > } > > > > @Nonnull > > private static int[] readVarintTable(@Nonnull DataInputStream in, > > @Nonnegative int sublength) throws IOException { > > int[] out = new int[readVarint(in) * sublength]; > > for (int i = 0; i < out.length; i++) > > out[i] = readVarint(in); > > return out; > > } > > > > static { > > try { > > DataInputStream in = new DataInputStream( > > new BufferedInputStream( > > Parser.class.getResourceAsStream("Parser.dat") > > ) > > ); > > table = readVarintTable(in); > > } // etc > > > > -- > You received this message because you are subscribed to the Google Groups > "mechanical-sympathy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "mechanical-sympathy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
