Missing stack traces after C1 code replaced with C2 code

[Krystal Mok]

Hi Ivan,

Actually I don't think this has anything to do with tiered compilation.

It could be that with tiered compilation turned on, the profile data is
gathered more quickly, so that it can see some certain exception throwing
site actually occured above some certain threshold (e.g. a potential NPE
throwing site that's hot), so when it goes to the C2 compile, C2 decides to
treat the site as a hot one, and would use the "fast throw" logic for that
site.

With tiered compilation turned off, the initial C2 compilation might
optimistically assume that the exception throwing sites aren't hot, and for
certain types of exceptions (e.g. NPE) the check could be implicit, so it's
not even using this fast throw logic yet. But, later on as the C2 compiled
code get executed for a longer time, it would still see some certain
throwing site are hot, so there would be a C2 recompile that would end up
exactly like what you're seeing with tiered turned on.

That feature is implemented here:
http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot/file/tip/src/share/vm/opto/graphKit.cpp#l548
As you can see, there are only a handful of types of exceptions treated
specially.

Omitting the stack traces in "fast throw" is a performance feature in C2,
and it has been there for many years now. So it's not a bug.
It can be optionally turned off with -XX:-OmitStackTraceInFastThrow, just
as you've seen, at the price of slower exception throwing for a couple of
exception types.

I wouldn't go as fas as recommending all Clojure users to turn off
OmitStackTraceInFastThrow by default, because there certainly could be a
performance hit. Just turn it off when you really need the stack trace.

HTH,
Kris


On Thu, Mar 20, 2014 at 11:28 PM, Ivan Kozik <ivan at ludios.org> wrote:

> Thanks Kris, I hadn't.  With -XX:-OmitStackTraceInFastThrow, I always
> see stack traces.
>
> Is this expected behavior?  It's a little surprising to see it only
> when code goes from C1->C2.
>
> Should Clojure be doing something so that users can see stack traces
> even without -XX:-OmitStackTraceInFastThrow?
>
> Thanks,
>
> Ivan
>
> On Fri, Mar 21, 2014 at 5:56 AM, Krystal Mok <rednaxelafx at gmail.com>
> wrote:
> > Hi Ivan,
> >
> > Looks like a OmitStackTraceInFastThrow kind of behavior. Have you tried
> > -XX:-OmitStackTraceInFastThrow to turn off that behavior and see what
> > happens?
> >
> > Thanks,
> > Kris
> >
> >
> > On Thu, Mar 20, 2014 at 10:46 PM, Ivan Kozik <ivan at ludios.org> wrote:
> >>
> >> There is a long-standing HotSpot bug in tiered compilation when it
> >> upgrades code from tier 3 to tier 4.  After this code upgrade happens,
> >> stack traces are repeatedly thrown away, at least in Clojure programs.
> >>
> >>
> >> Repro steps are:
> >>
> >> wget
> >>
> http://repo2.maven.org/maven2/org/clojure/clojure/1.6.0-RC1/clojure-1.6.0-RC1.jar
> >> rlwrap java -jar clojure-1.6.0-RC1.jar
> >> (inc nil) (pst)
> >>
> >> keep repeating (inc nil) (pst) until you see:
> >>
> >> NullPointerException   [trace missing]
> >>
> >>
> >> or, to avoid having to hit Up/Enter as much:
> >>
> >> (dotimes [_ 1000] (try (inc nil) (catch Throwable e (.printStackTrace
> >> e))))
> >>
> >> which will usually require just 2 invocations, but sometimes up to 5.
> >>
> >>
> >> I see this bug in both IcedTea and Oracle Java 7 and 8, on all of
> >> Ubuntu, Windows 7, and Mountain Lion.  I don't see the bug when
> >> TieredCompilation is turned off, or when it is limited to tier 3.
> >>
> >> This was originally discovered in
> >> https://github.com/technomancy/leiningen/issues/1025 and the
> >> workaround (for leiningen users) was to limit the compilation tier.  I
> >> expect that Clojure users will be running into this problem more
> >> frequently now that tiered compilation is on by default.
> >>
> >> Unfortunately, I am not familiar with the internals of
> >>
> >>
> https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java
> >> to know if Clojure might be doing something peculiar with JVM
> >> bytecode.  It wouldn't be something new; Clojure 1.0, 1.1, 1.2.1, 1.3,
> >> 1.4, 1.5.1, and 1.6.0-RC1 are affected.
> >>
> >> I originally reported this to bugs.sun.com in February 2013 and it was
> >> assigned internal review ID 2456988.  AFAIK, the bug did not make it
> >> into bugs.sun.com or bugs.openjdk.java.net.  I later asked #openjdk
> >> about it and was told to report it here.
> >>
> >>
> >> Thanks,
> >>
> >> Ivan
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20140320/06098988/attachment.html>