Missing stack traces after C1 code replaced with C2 code

[Ivan Kozik]

Hi Kris,

Thanks!  I just noticed that the stack traces eventually disappear
even without tiered compilation.  I never noticed before, because it
takes a lot longer.  I should have tested a little more thoroughly!

Thank you for the detailed implementation info.

Ivan

On Fri, Mar 21, 2014 at 6:45 AM, Krystal Mok <rednaxelafx at gmail.com> wrote:
> 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
>> >
>> >
>
>