----- Mail original -----
> De: "Jochen Theodorou" <blackd...@gmx.org>
> À: jvm-languages@googlegroups.com
> Envoyé: Mercredi 16 Mars 2016 13:45:18
> Objet: Re: [jvm-l] slow downs in invokedynamic native code
>
>
>
> On 16.03.2016 12:41, Remi Forax wrote:
> > The symptoms are really like a deoptimization storm,
> > setCallSiteTargetNormal goes to a safepoint (which is worst that only
> > having the compiler/JIT lock because all threads are stopped),
> > when either a code calls setTarget or a SwithPoint is invalidated.
> >
> > You have a deopt storm when the JIT compiles a code that contains a
> > callsite that is always invalid, so the VM enters in loop like this,
> > JIT compile a blob
> > execute the blob
> > deopt
> > jump back in the interpreter
> > rinse and repeat
> >
> > The root cause is a bug in the invalidation logic of the language
> > runtime (not the VM) but it's hard to spot without a reproducible test
> > case because
> > when the JIT compiles a blob of codes there are several callsites inside
> > that blob and usually only one is the faulty one.
>
> yeah, the test case is a problem... assuming you have code like this
>
> def foo(X x) {
> x.bar() // callsite to discuss here!
> }
> class X {def bar(){1}}
> class Y extends X {def bar(){2}}
>
> 10_000_000.times {
> foo(new X())
> foo(new Y())
> }
>
> and assuming you have the logic, that you call always X::bar for
> instances of X and Y::bar for instances of Y, meaning in this case you
> will gave to set the target of the callsite again and again for every
> call. Would that be a case like you are talking about?
>
> If yes, I would be wondering why JIT compilation happens on the first
> time here already... that's not what I do remember from invokedynamic.
> If there have to be several (1000+) calls of the same type first, then
> it should be still far from a deoptimization storm, or not?
let consider a slightly different code,
def foo(X x) {
x.bar() // callsite to discuss here!
}
class X {def bar(){1}}
class Y extends X {def bar(){2}}
1_000.times {
10_000.times {
foo(new X())
}
foo(new Y())
}
in that case, foo(new X()) is executed enough time to trigger the JIT, and the
call foo(new Y()) will ask for a deopt
(and having several threads hammering this code will make the problem worst).
>
> If this is indeed the kind of bug we are talking about, then the
> solution would be to implement caching for morphic callsites.
or just stop to do any caching by having a callsite doing a fold + exactinvoker
with the combiner of the fold returning a non constant method handle
> On the other side I find it interesting I find it interesting, that we won't
> get the problem with non-indy. But maybe it can be explained by a more
> eager optimizing JIT (or getting out of interpreter mode at all)
>
if there are no indy, hotspot doesn't consider the method implementation has
being constant, thus there is no issue because the JIT will not try to inline it
> > We already have discussed about that point several times,
> > John is a proponent of marking the callsite has should never be
> > optimized again,
> > which at least stop the storm issue but it sweeps the real cause of the
> > bug under carpet,
>
> yeah, I would not like to have that as well.
>
> > I would prefer, consider these kind of bugs as a language runtime bugs
> > that should be investigated by the runtime developers.
> >
> > Perhaps a middle ground is to mark the callsite as not compilable
> > anymore *and* emit a warning (like when the code cache is full) to not
> > hide the root cause of the bug.
>
> How about showing those faulty callsites in jvisualvm or have another
> inspection tool for that?
yes, any form of logging, a mbean that exports information about non compilable
call sites is fine too.
>
>
> bye Jochen
Rémi
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jvm-languages+unsubscr...@googlegroups.com.
To post to this group, send email to jvm-languages@googlegroups.com.
Visit this group at https://groups.google.com/group/jvm-languages.
For more options, visit https://groups.google.com/d/optout.
