Netbeans has a profiler built in, though I don't know how well it works and I
don't know if it's been updated for 292. The Sun Studio Analyzer does a very
good job capturing profiles without a lot of overhead though it only runs on
Solaris and Linux. The very latest version supports 292 but I
Remi, I've made the vtable + migration to some builtin j.l.* types
Do you mind to take a look?
https://github.com/dynjs/dyn.js/blob/master/src/main/java/org/dynjs/runtime/linker/PrimitivesLinker.java
https://github.com/dynjs/dyn.js/blob/master/src/main/java/org/dynjs/runtime/linker/VTablePopulat
On 10/17/2011 10:30 PM, Charles Oliver Nutter wrote:
> It seems like the natural solution! :) Invokedynamic is nothing
> without the handles wiring it up...so they should always live happily
> together in the land of fairies and unicorns.
no pony :(
>
> - Charlie
Rémi
__
It seems like the natural solution! :) Invokedynamic is nothing
without the handles wiring it up...so they should always live happily
together in the land of fairies and unicorns.
- Charlie
On Mon, Oct 17, 2011 at 5:32 PM, Christian Thalinger
wrote:
> You are really advocating this :-)
> -- Chri
That seems to be a bug. hprof needs to be updated for 292. I filed 7101843
for this.
tom
On Oct 13, 2011, at 8:53 PM, Charles Oliver Nutter wrote:
> FWIW, option 2 (hprof) seems like a no-show on u2b08:
>
> headius@headius-vbox-ubuntu:~/projects/redblack$
> JAVA_HOME=~/jdk1.7.0_02/ ../jruby/
You are really advocating this :-)
-- Chris
On Oct 17, 2011, at 7:11 PM, Charles Oliver Nutter wrote:
> More justification for this...
>
> Not inlining the handles would be like invokevirtual not emitting its type
> check inline and doing that as a separate CALL. Handles are our way to tell
>
More justification for this...
Not inlining the handles would be like invokevirtual not emitting its type
check inline and doing that as a separate CALL. Handles are our way to tell
the JVM what native operations go with an invokedynamic. Not emitting those
operations unconditionally into the comp
Yeah that does sound like the right approach the more I think about it. The
invokedynamic operation and the handles that wire it up should never be
separated. Pathology aside, I know the JRuby logic would remain pretty small
in almost every case. And pathological cases could be detected with some
k
On Oct 17, 2011, at 4:14 PM, Charles Oliver Nutter wrote:
> Yeah that's a pretty big problem :) Indy almost becomes a nonstarter if these
> degraded cases are not made a lot better. The performance on this example
> becomes terrible, and it's common for Ruby methods to be larger and more
> com
Yeah that's a pretty big problem :) Indy almost becomes a nonstarter if
these degraded cases are not made a lot better. The performance on this
example becomes terrible, and it's common for Ruby methods to be larger and
more complex than this, too.
You say you don't know how to fix it, so perhaps
On Oct 15, 2011, at 2:56 PM, Charles Oliver Nutter wrote:
> I'm seeing something peculiar and wanted to run it by you folks.
>
> There are a few values that JRuby's compiler had previously been
> loading from instance fields every time they're needed. Specifically,
> fields like ThreadContext.ru
11 matches
Mail list logo
