Explicit catches versus bulk catch + type check?
Ok Hotspot guys, I have a challenge for the JIT. I want to basically do this:
try {
...
} catch (Exception e) {
if (!(e instanceof SomeException)) throw e;
... handle e as SomeException
}
instead of explicitly adding exception-handling for SomeException.
There's a few reasons for this:
* Wiring up exception-handling in method handles is rather cumbersome.
If I could do it with a single wrapper it would make my life easier.
* Similar to the "multicatch" problem in Java 7, I often want nearly
the same boilerplate code for multiple exception types.
* Because Ruby is dynamically typed, we can't statically determine the
*actual* expected exception type at compile time, and so we must do a
bulk catch with type checks.
My question, then, is whether Hotspot can see through this (assuming
everything inlines) and see that although we're doing a bulk catch
only certain cases *actually* handle the resulting exception.
Thoughts?
- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Profiling + Indy
FWIW, option 2 (hprof) seems like a no-show on u2b08: headius@headius-vbox-ubuntu:~/projects/redblack$ JAVA_HOME=~/jdk1.7.0_02/ ../jruby/bin/jruby -X+C -J-Xrunhprof:cpu=times bm1.rb 20 HPROF ERROR: Unknown constant [../../../src/share/demo/jvmti/java_crw_demo/java_crw_demo.c:693] [hprof_init.c:210] HPROF TERMINATED PROCESS So I'm stuck with sampling. - Charlie On Fri, Oct 14, 2011 at 3:52 AM, Charles Oliver Nutter wrote: > I'm looking to get back into JRuby + Indy work now that the heaviest > conferences are behind me. Part of this involves running larger > benchmarks where the hot spots may not be apparent at a glance. In > order to investigate performance on such benchmarks, I will want to do > some profiling. But what should I use? > > For really egregious problems, the sampling profiler (-Xprof) "sort > of" works. It's grossly inaccurate when there's no stand-out hotspot, > but if something is incredibly bad it usually shows it. So that's > option 1. > > There's -Xrunhprof:cpu=times, which is more accurate, but the impact > to running code is enormous, there's no way to filter out > uninteresting code (like JDK core), and I have no idea if it works > properly with indy (given that there's ongoing work to make JVMTI + > indy play nice). That's option 2. > > Are either of these options any good? What else do you recommend? > > - Charlie > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Profiling + Indy
I'm looking to get back into JRuby + Indy work now that the heaviest conferences are behind me. Part of this involves running larger benchmarks where the hot spots may not be apparent at a glance. In order to investigate performance on such benchmarks, I will want to do some profiling. But what should I use? For really egregious problems, the sampling profiler (-Xprof) "sort of" works. It's grossly inaccurate when there's no stand-out hotspot, but if something is incredibly bad it usually shows it. So that's option 1. There's -Xrunhprof:cpu=times, which is more accurate, but the impact to running code is enormous, there's no way to filter out uninteresting code (like JDK core), and I have no idea if it works properly with indy (given that there's ongoing work to make JVMTI + indy play nice). That's option 2. Are either of these options any good? What else do you recommend? - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
On 10/13/2011 04:24 PM, Douglas Campos wrote: > Remi, >>> By example, for javascript Number, it should be a j.l.Double but with >>> it's own vtable > when you talk about having a vtable, you mean the "verified-entrypoint" > recipe from jsr292 cookbook? (or something into these lines) > > So I would be providing "more methods" to a j.l.Double, linking with static > methods via methodhandles? yes, but the vtable of the VEP tailor its method handles in a very special way, a vtable storing simple method handles is enough. > cheers > -- qmx Rémi ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: dyn.js - invokedynamic-based js implementation
Remi, >> By example, for javascript Number, it should be a j.l.Double but with >> it's own vtable when you talk about having a vtable, you mean the "verified-entrypoint" recipe from jsr292 cookbook? (or something into these lines) So I would be providing "more methods" to a j.l.Double, linking with static methods via methodhandles? cheers -- qmx ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
