I suspect that the build phase of an app using Graal AOT could suffer the
same limitation, but it is correct that static initializers *shouldn't* be
used for heavyweight computations given that are ensured to be called
serially...
Il giorno ven 8 feb 2019, 02:36 Andrei Pangin ha
scritto:
> Looks
Looks like you run long computation inside the static initializer ,
right?
The problem is that HotSpot cannot fully optimize static calls when the
holder class is not completely initialized. Moving computation to a
separate class is the right way to deal with such cases.
The situation got even
Profile it with Solaris Studio(yes you can!), this should give you insight into
the assembly level as well.
The code may have been compiled by c1, or c2, but you are correct that if you
see a symbol in perf-map-agent then it is definitely compiled.
Can you reproduce the issue in a minimal JMH ben
Hmm... "Justify/explain your beliefs." Fair, I'm game:
I think I'm sure that my methods are both JIT'd because perf-java-flames
shows them both in green, and I think that's derived from some prefix on
the symbol name where the JVM (via perf) says it's JIT'd. If it weren't
JIT'd, I'd see it lis
On Mon, Feb 4, 2019 at 9:13 PM Shevek wrote:
> This isn't a JIT issue. According to perf-java-flames, all my code DID
> get jitted. The overhead is entirely calls to this mystery
> resolve_static_call function, so it looks like a static method lookup
> issue in the JVM. The shape of the stack pro
This isn't a JIT issue. According to perf-java-flames, all my code DID
get jitted. The overhead is entirely calls to this mystery
resolve_static_call function, so it looks like a static method lookup
issue in the JVM. The shape of the stack profile makes it look as if
something is recursive, to
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 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
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 releva
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:
-> readVarintTable (90%), of which:
readVarintTable -> readVarint (4%)
readVarintTable -> resolve_static
