Nuke it from orbit. It's the only way to be sure.
On Mon, Mar 28, 2011 at 3:57 PM, Ben Evans
wrote:
> I say get rid of vestigial packages / names as soon as possible.
>
> Thanks,
>
> Ben
>
> On Mon, Mar 28, 2011 at 9:02 PM, John Rose wrote:
>>
>> OpenJDK b135 has JVM support for the new package
Sorry :) Busy busy busy. I'll try to have a look soon.
If you feel up to it, filing a bug at http://bugs.jruby.org would make
sure we don't forget about it, and would act as another ping.
- Charlie
On Mon, Mar 28, 2011 at 4:30 AM, Christian Thalinger
wrote:
> On Mar 24, 2011, at 4:06 PM, Christ
I'd use it if there, but we already generate so much bytecode at
runtime, including non-Proxy "real" implementations of interfaces,
that it's really not a big deal if it isn't there.
However...the fact that I *would* use it means that eventually I
*will* use it, which then means yet another item I
1. You can pass -d to JRuby to get the debug output from the failure,
or -Xjit.logging.verbose=true. I can take a look at this as soon as I
can update to java.lang.invoke.
2. I can fix the package reference quickly, but I'm using Rémi's
backport/mock which is still on java.dyn. I can't commit chan
On Wed, Apr 6, 2011 at 10:36 AM, Rémi Forax wrote:
> On 04/06/2011 05:17 PM, Charles Oliver Nutter wrote:
>> 2. I can fix the package reference quickly, but I'm using Rémi's
>> backport/mock which is still on java.dyn. I can't commit changes to
>> JRuby master
On Wed, Apr 6, 2011 at 11:17 AM, Rémi Forax wrote:
> you can still run using the old linkage API (for 2 or 3 builds)
> using -XX:+allowTransitionalJSR292
Ok, I'll do that for now. I assume Linkage is still in the mock?
>>
>> What's the golden path forward at this point? Is indy solidified
>> eno
On Wed, Apr 6, 2011 at 11:22 AM, Charles Oliver Nutter
wrote:
> Ok, I'll do that for now. I assume Linkage is still in the mock?
Linkage does not appear to be in the mock, either under java.dyn or
java.lang.invoke.
- Charlie
___
mlvm-dev mail
On Wed, Apr 6, 2011 at 11:24 AM, Charles Oliver Nutter
wrote:
> On Wed, Apr 6, 2011 at 11:22 AM, Charles Oliver Nutter
> wrote:
>> Ok, I'll do that for now. I assume Linkage is still in the mock?
>
> Linkage does not appear to be in the mock, either under java.dyn or
>
this to JRuby master once ASM 4 is out.
- Charlie
On Wed, Apr 6, 2011 at 11:45 AM, John Rose wrote:
> On Apr 6, 2011, at 9:35 AM, Charles Oliver Nutter wrote:
>
> And the flag does not seem to work either :(
>
> [apt] Warning: The flag +AllowTransitionalJSR292 has been EOL'd as
On Wed, Apr 6, 2011 at 5:45 PM, Kirill Shirokov
wrote:
> The compilation error is most probably caused by package rename:
>
> warning: could not compile: bench/bench_fib_recursive.rb; full trace follows
> java.lang.NoClassDefFoundError: java/dyn/CallSite
> at
> org.jruby.runtime.invokedyna
Today I played a bit more with expanding our use of invokedynamic in
JRuby. The experiment today was to replace direct guarded calls with
indy calls.
Specifically, when calling an operator (+, -, <, etc) with a literal
integer, we use a different call site that checks instanceof
RubyFixnum and cal
On Sun, Apr 10, 2011 at 6:15 PM, Rémi Forax wrote:
> I think you can fix a little bit your implementation:
> First instead of sending the name of the operation at each call
> you should use the indy name to encode that name
> instead of pushing it on the stack.
> So fixnumFallback should bind the
I prepared this for someone else, but I thought folks here might be
interested in it too.
This gist contains hotspot x86 (32-bit) assembly output for JRuby's
dynopt mode and invokedynamic (on a couple-week-old OS X OpenJDK
build). I haven't spent a lot of time investigating.
https://gist.github.c
Yay!
On Wed, Mar 23, 2011 at 4:10 AM, John Rose wrote:
> http://cr.openjdk.java.net/~jrose/7012648/webrev.jdk.00/
>
> Summary: JDK code for package and class renaming from java.dyn to
> java.lang.invoke.
>
> Includes certain other small changes:
> - move remaining (miscellaneous) contents of su
I assume this means invokeGeneric is firmly established in the
specification. I would agree with "invoke" as well.
On Sun, Mar 27, 2011 at 1:27 AM, Jeroen Frijters wrote:
> +1 invoke makes sense.
>
>> -Original Message-
>> From: mlvm-dev-boun...@openjdk.java.net [mailto:mlvm-dev-
>> boun.
FYI I have finally pushed my indy updates to JRuby master for eventual
release in JRuby 1.7. I have also removed the indy_update branch,
since all those changes are now on master.
- Charlie
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.
I think it's time to start talking about what we'd need to do to get
coroutines in Java 8.
In the absence of forking, lightweight processes, or M:N threading,
there's no efficient way to implement a large set of problems that
demand fiber/coroutine-like behavior. Add to that the fact that
language
On Wed, Apr 27, 2011 at 2:54 PM, Rémi Forax wrote:
> Yes, 100% agree.
> Coroutine can also be used to implement generators in Java,
> introducing yield in the release that introduce lambda make a lot of
> sense for me.
Yeah, the Java platform is moving toward:
* Lightweight concurrency models (
On Thu, Apr 28, 2011 at 5:16 AM, Christian Thalinger
wrote:
> I took a look at it. I used 64-bit x86 since the code is a bit smaller than
> with 32-bit.
>
> The code is almost identical but three things popped into my eye (the output
> is from PrintOptoAssembly):
>
> 1. The obvious one: the me
On Thu, Apr 28, 2011 at 8:19 AM, Charles Oliver Nutter
wrote:
> I've been trying to think of ways to reduce the guard cost, since the
> perf without the JRuby guard is a fair bit better (0.79 versus 0.63s
> for fib(35)). The performance without guards is actually faster than
&g
On Thu, Apr 28, 2011 at 5:03 AM, Lukas Stadler wrote:
> I totally agree as well, naturally :-)
>
> And I do plan on spending more time on the coroutine patch again, I
> didn't do much coding in the last months because I was occupied at
> university.
> The result of this is my thesis on coroutines:
On Thu, Apr 28, 2011 at 9:17 AM, Christian Thalinger
wrote:
> I have now a patch that makes the command line switch tweaking superfluous
> and the default performance looks pretty good (see below, 32-bit x86).
That's excellent! I can't wait to see that land.
A couple notes I haven't included in
On Thu, Apr 28, 2011 at 11:03 AM, Rémi Forax wrote:
> On 04/28/2011 03:56 PM, Charles Oliver Nutter wrote:
>> stack map is invalid. Could be an ASM bug?
>
> yes. it could :)
>
> Also it could be a bug on your side because to calculate stackmap
> ASM needs to be able to f
On Thu, Apr 28, 2011 at 11:18 AM, Rémi Forax wrote:
>>> > Any thoughts on how we can make this even faster? The bulk of the code
>>> > seems to be taken up by a few operations inherent to Fixnum math:
>>> >
>>> > * Memory accesses relating to CallSite subclasses (LtCallSite and
>>> > friends)
On Thu, Apr 28, 2011 at 11:41 AM, Rémi Forax wrote:
> Lukas, if you refresh your patch, we can come at the next JVM Summit in
> July with
> a web server that use co-routine with nio/asyncio plus some examples
> of yield/iterator/generator.
And I promise to finally get coroutine-based fibers into
I'm trying to figure out why polymorphic dispatch is incredibly slow
in JRuby + indy. Take this benchmark, for example:
class A; def foo; end; end
class B; def foo; end; end
a = A.new
b = B.new
5.times { puts Benchmark.measure { 100.times { a, b = b, a; a.foo;
b.foo } } }
a.foo and b.foo ar
?
>
> Cheers
>
> On 2011-04-29 09.59, Rémi Forax wrote:
>> On 04/28/2011 09:58 PM, Charles Oliver Nutter wrote:
>>> I'm trying to figure out why polymorphic dispatch is incredibly slow
>>> in JRuby + indy. Take this benchmark, for example:
>>>
up turning into a CALL
(vtable? IC?)
This is fun :)
- Charlie
On Fri, Apr 29, 2011 at 3:12 PM, Charles Oliver Nutter
wrote:
> I think my strategy is going to be something like this:
>
> * Bind first method encountered straight through with a new GWT
> * Upon encountering nth new
On Sat, Apr 30, 2011 at 2:27 AM, Charles Oliver Nutter
wrote:
> I have pushed a change to JRuby master that fails over to a simple
> inline cache after one failed GWT. This is not how I would want to do
> it long-term, but it does bring some benchmarks back in line with
> no
commit is 989 and
the property to configure is jruby.invokedynamic.maxfail, which should
equal the number of GWT it will attempt to chain before failing over
to simple IC.
Awesome stuff.
- Charlie
On Sat, Apr 30, 2011 at 2:27 AM, Charles Oliver Nutter
wrote:
> I have pushed a change to JRu
On Sun, May 1, 2011 at 1:01 PM, Mark Roos wrote:
> With respect to chaining gwt handles.
>
> Any thoughts on at what depth the chain should be converted to some other
> form of dispatch?
> I am currently just letting them build
>
> In smalltalk it seems that around 10-20 inline tests are about the
On Thu, Apr 28, 2011 at 11:18 AM, Rémi Forax wrote:
> Do you specialize the overflow check depending on the callsite ?
> for fib(n - 1), you just have to check if n is different from
> Integer.MIN_INT,
> for fib(n - 2), if n is <= to Integer.MIN_INT - 1
> and for + use the double xor tricks.
Here
:
> On May 3, 2011, at 5:06 PM, Rémi Forax wrote:
>> On 05/03/2011 03:59 PM, Christian Thalinger wrote:
>>> On May 2, 2011, at 9:55 PM, Charles Oliver Nutter wrote:
>>>> On Thu, Apr 28, 2011 at 11:18 AM, Rémi Forax wrote:
>>>>> Do you specialize
Brainstorming coro package names...
java.lang.invoke isn't bad, perhaps, but it is a different form of invocation
than invokedynamic.
This is a core JVM feature, so something under java.lang seems appropriate in
any case...
java.lang.coroutine (or coro) is maybe too specific?
How far off woul
long result,
MathOperation op) where MathOperation is an enum of operations for which we
want to detect overflow. Enums don't present any sort of barrier to
intrinsification, do they?
- Charlie (mobile)
On May 3, 2011, at 15:51, Rémi Forax wrote:
> On 05/03/2011 10:29 PM, Charles Oliver
I finally updated BiteScript to support invokedynamic, and added a
simple example:
https://gist.github.com/961054
This basically just binds the given name + signature to a static
method on the same class (the script class), using a ConstantCallSite.
Probably the simplest-possible example in "raw"
FYI, this produced a SIGSEGV:
jruby --server bench/shootout/binarytrees.ruby-2.ruby 15
14 and lower worked ok. Crash is consistent. Running macosx build from
4/28...not sure what build of mainline it maps to...
~/projects/jruby ➔ java -version
openjdk version "1.7.0-internal"
OpenJDK Runtime Env
On Mon, May 9, 2011 at 9:33 AM, Christian Thalinger
wrote:
> On May 9, 2011, at 3:34 PM, Charles Oliver Nutter wrote:
>> FYI, this produced a SIGSEGV:
>>
>> jruby --server bench/shootout/binarytrees.ruby-2.ruby 15
>
> Is invokedynamic now used by default? -- Christ
I'm at a loss for how to debug something like this:
MethodHandleNatives.java:336:in `raiseException':
java.lang.ClassCastException: required class org.jruby.RubyFixnum but
encountered class org.jruby.RubyObject
from MethodHandleImpl.java:866:in `invoke_L5'
from bench/bench_fib_recu
JRuby invokedynamic bindings that use catchException appear to blow up
with a current MLVM build (as of a few minutes ago). The error is the
same in every case:
Caused by: java.lang.IllegalArgumentException: spread on
invoke_F9(CacheEntry,ThreadContext,IRubyObject,IRubyObject,String,IRubyObject,IR
I've been making more and more JRuby paths use invokedynamic, and
trying to get more of those to bind straight through with
methodhandles (rather than via our intermediate DynamicMethod class).
Most numbers are looking great...even some benchmarks against core
JRuby methods that are implemented in
. Thanks, Charlie, for all of your incredibly
> constructive input to JSR 292! -- John
>
> On Apr 27, 2011, at 10:34 AM, Charles Oliver Nutter wrote:
>
>> FYI I have finally pushed my indy updates to JRuby master for eventual
>> release in JRuby 1.7. I have also removed
12, 2011 at 8:58 AM, Charles Oliver Nutter
wrote:
> JRuby invokedynamic bindings that use catchException appear to blow up
> with a current MLVM build (as of a few minutes ago). The error is the
> same in every case:
>
> Caused by: java.lang.IllegalArgumentException: spread on
&
h, without an intermediate Object[] box? I do
need to rework how these handles are wired up, but I may still get
close to this 10-arg failover in some cases.
- Charlie
On Sat, May 14, 2011 at 10:06 AM, Charles Oliver Nutter
wrote:
> Still getting an error, but it's different now (updated using
>
Current build as of an hour ago. Made some changes to bind more
handles straight through, and got this:
~/projects/jruby ➔ jruby -d -X+C --server -e "class Foo; attr_accessor
:bar; end; f = Foo.new; loop do; f.bar; end"
argCount: 4
inbound:
(ThreadContext,IRubyObject,IRubyObject,String,IRubyObjec
FYI, I assume I'm supposed to see this when I bind an interface method
acquired from findVirtual to an indy call site:
#
# A fatal error has been detected by the Java Runtime Environment:
#
# Internal Error (methodHandleWalk.cpp:), pid=24843, tid=2962804736
# Error: Unimplemented()
#
# JRE v
ons we have the Object[] box are (1) SPARC doesn't
> support RF's yet, and (2) we haven't transitioned all the transform-building
> code non-boxing. Working with GWT today; would like to fix the exception
> problem at the same time; need a representative test case.
>
I think I updated correctly, but still seem to run into the
catchException issue...attempting to confirm now.
On Sun, May 15, 2011 at 4:11 AM, wrote:
> Changeset: 2cd2529d803f
> Author: jrose
> Date: 2011-05-15 02:10 -0700
> URL: http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/2cd2529
Very cool! I am glad someone with the requisite skills has begun looking into
John's tuples post!
I am not an expert on Hotspot internals, so I am afraid I can't respond to your
query. But we (JRuby and other dynlangs) most definitely have a need for tuples
in representing complex numeric boxes
Ok, nevermind...looks like it wasn't applied by Stephen's
script...perhaps it's not marked as ready yet?
I will be patient :)
- Charlie
On Sun, May 15, 2011 at 11:27 AM, Charles Oliver Nutter
wrote:
> I think I updated correctly, but still seem to run into the
>
Can I get a rough guesstimate from the JVM guys how much more overhead
is involved in accessing a never-changed MutableCallSite versus a
ConstantCallSite? I have a few places where I want to use
invokedynamic to lazily initialize some literals. They'll never change
after the initial construction, b
On Sun, May 15, 2011 at 8:20 PM, Stephen Bannasch
wrote:
> It looks like both meth-args-6983728 and meth-exc-7044892 in that changeset
> are being applied to the jdk.
I'll give it another shot. I admit my methodology was possibly
flawedI looked for changes in those patches to be in the JDK
s
Ok, nevermind...now the Java test case works for me. Odd that a simple
update.sh didn't seem to do it before...
Thanks!
On Mon, May 16, 2011 at 7:48 AM, Charles Oliver Nutter
wrote:
> On Sun, May 15, 2011 at 8:20 PM, Stephen Bannasch
> wrote:
>> It looks like both meth-args
Oh, somehow I missed this email too. Yes, the test case does indeed work now!
- Charlie
On Mon, May 16, 2011 at 2:46 AM, John Rose wrote:
> On May 15, 2011, at 4:05 PM, Charles Oliver Nutter wrote:
>
>> I will be patient :)
>
> I just posted the one-line tweak which makes your
> On 05/16/2011 09:48 AM, Christian Thalinger wrote:
>> It seems nobody (including me) has ever bound an interface before that was
>> hot to be compiled in the compiler. I need a small test case to add the
>> missing code (which should be trivial).
I will try to come up with something later tod
On Mon, May 16, 2011 at 2:50 AM, Rémi Forax wrote:
> Theoretically, the is no speed difference between a ConstantCallSite
> and a MutableCallSite that at some point never mutate.
> The difference is more that a MutableCallsite has to keep metada
> to trigger a de-optimization and not the Constant
FYI, this is now the primary issue keeping me from continuing to wire
up invokedynamic paths in JRuby. Have not yet reduced a test case for
it.
- Charlie
On Sat, May 14, 2011 at 11:26 AM, Charles Oliver Nutter
wrote:
> Current build as of an hour ago. Made some changes to bind more
> h
A trivial reproduction against my JRuby working copy:
def control
end
100.times { control }
It seems to have something to do with the block...doing the "control"
call alone works ok.
- Charlie
On Mon, May 16, 2011 at 10:13 AM, Charles Oliver Nutter
wrote:
> FYI, this is no
Very nice, thanks. I've been using your scripts to stick to MLVM head
lately. Aside from the usual frustration of riding the bleeding edge,
the builds work perfectly.
Does anyone know about the dev cycle for the macosx port? I almost
wonder if it would be possible to rebase the patches against tha
tly changing an arg to void:
change_argument(T_OBJECT, arg_slot, T_VOID, ArgToken(tt_void));
So perhaps the switch at methodHandleWalk.cpp:1092 hasn't been updated
for whatever logic needed this void transformation?
- Charlie
On Mon, May 16, 2011 at 10:21 AM, Charles Oliver Nutter
wrote:
>
On Mon, May 16, 2011 at 12:09 PM, Stephen Bannasch
wrote:
> They now seem to be pulling in upstream changes quite quickly.
>
> Last Thursday they pulled in jdk7-b141:
>
> http://hg.openjdk.java.net/macosx-port/macosx-port/hotspot/rev/66b35d6aefbe
Very nice! Then the lag time for some of these up
On Mon, May 16, 2011 at 2:38 PM, Stephen Bannasch
wrote:
> The format for how guards are expressed is a bit confusing -- preceding a
> patch with a '/' turns that patch off.
>
> So this line builds without coro:
>
> export davinci=$(pwd) guards="buildable testable /coro"
Confusing is one word f
Confirmed here too. And since it wiped out my previous copy I'm dead
in the water at the moment :(
- Charlie
On Tue, May 17, 2011 at 8:24 AM, Ola Bini wrote:
> Hi,
>
> It seems something has introduced a failure. Updating from the bsdport
> and patches repo with default settings for Stephens scr
Ok, updating now to check it out. Thanks John!
On Tue, May 17, 2011 at 1:04 PM, John Rose wrote:
> Sorry folks. Stubborn rt.jar classes won't go quietly into that good night.
> Marked the new patch -buildable. -- John
>
> On May 17, 2011, at 10:58 AM, Charles Ol
On Tue, May 17, 2011 at 12:08 PM, Mark Roos wrote:
> It looks like JVMTI supports this but I have not been able to find a Java
> class which gives access to the
> apis that look interesting.
>
> Is this the right way to go?
>
> Does anyone know of some existing work that I could leverage?
There's
lem...
# Internal Error (methodHandleWalk.cpp:1092), pid=53532, tid=4401328128
# Error: ShouldNotReachHere()
On Tue, May 17, 2011 at 1:07 PM, Charles Oliver Nutter
wrote:
> Ok, updating now to check it out. Thanks John!
>
> On Tue, May 17, 2011 at 1:04 PM, John Rose wrote:
>> Sorry folks. Stubb
The invokedynamic-related compiler stuff is a bit fluxxy right now, so
you may run into MLVM builds that don't work quite right. However, it
occurred to me today that you can still run with -Xint (interpret
only) to at least continue hacking away on JSR292 stuff. I'm doing
this now locally to keep
On Wed, May 18, 2011 at 5:34 AM, Szymon Jachim wrote:
> I have to questions to you guys about possible (and planned) JIT
> optimizations for MethodHandles.
> 1. Assuming that there will be a chain of MH's:
> mh1(invoker) -> mh2 -> aMethod()
> and there will be no other references to mh2.
I concur...still getting the ShouldNotReadHere error on most things I
run with JRuby + indy...
- Charlie
On Wed, May 18, 2011 at 3:48 AM, Ola Bini wrote:
> Hi,
>
> The latest fix to make methodHandleWalk.cpp not crash doesn't seem to
> cover all cases. I still get the same error:
>
> # A fatal e
On Thu, May 19, 2011 at 12:51 PM, Ola Bini wrote:
> I'm currently getting this error:
>
> Caused by: java.lang.IllegalArgumentException: too many values to insert
> at
> java.lang.invoke.MethodHandleStatics.newIllegalArgumentException(MethodHandleStatics.java:89)
> at
> java.lang.in
In Ruby, constants...aren't. They're *mostly* constant, but they have
to be looked up dynamically via the lexical scope and self class
hierarchy. They can be changed after the fact, and class modifications
like mixing in a module later will change the scenery, but these sorts
of changes are very ra
I have cases where I want to do some pre and post-call logic around a
target handle. Basically, I need to twiddle some global state before
and after to set up one of our artificial call frames for the target
method to use. How could I do this in handles?
The logic basically looks like this:
preLo
On Thu, May 19, 2011 at 3:53 PM, John Rose wrote:
> If you do a fold with a void return, nothing gets inserted into the argument
> list.
>
> The doc for this needs to be fixed, but the implementation should work now.
Hah...the original subject of my email was "foldArguments with void
return poss
On Thu, May 19, 2011 at 4:00 PM, John Rose wrote:
> Cool! That's one of the key use cases for SwitchPoint envisioned by the
> Expert Group. Please tell us ASAP if something goes wrong with the API!
> (The implementation we can fix, but the API is going more cryogenic as each
> day passes.)
Onl
Ok, good news first. The recent drop of fixes from Hotspot seem to
have fixed the problems in methodHandleWalk.cpp. Hooray!
The bad news is that performance seems to have *severely* degrade
since previous builds.
Here's JRuby running something simple, the fib benchmark:
~/projects/jruby ➔ jruby
On Thu, May 19, 2011 at 11:25 PM, Charles Oliver Nutter
wrote:
> Ok, good news first. The recent drop of fixes from Hotspot seem to
> have fixed the problems in methodHandleWalk.cpp. Hooray!
>
> The bad news is that performance seems to have *severely* degrade
> since previou
On Fri, May 20, 2011 at 1:07 AM, Ola Bini wrote:
>> Try -XX:+UnlockDiag* -XX:-UseRicochetFrames for differential testing.
>>
>> If you can find a microbenchmark which shows differential slowdown, we can
>> debug it.
>
> When trying the above all my tests fail with this:
> java.lang.RuntimeExcept
On Thu, May 19, 2011 at 4:55 PM, John Rose wrote:
> The last MH.invoke in my sketch could also be the indy instruction, with the
> preceding stuff executed in the BSM.
>
> The basic idea is to package the wrapping logic in a target-independent form,
> and bind it (pre-packaged) to each call site
On Thu, May 19, 2011 at 3:53 PM, John Rose wrote:
> Your sketch seems good, except that you cannot handle both the return value
> and the thrown exception in one place. (API limitation.) So if your post
> logic wants to see the return value, you have more work to do.
>
> Suggestion: Make the
runtime.callsite.MinusCallSite::call@24 (line 16)
On Fri, May 20, 2011 at 8:10 AM, Charles Oliver Nutter
wrote:
> On Fri, May 20, 2011 at 1:07 AM, Ola Bini wrote:
>>> Try -XX:+UnlockDiag* -XX:-UseRicochetFrames for differential testing.
>>>
>>> If you can fi
harlie
On Fri, May 20, 2011 at 2:59 PM, Charles Oliver Nutter
wrote:
> Another update...I managed to turn off the ricochet frames and have it
> still work (???). The with-ricochet mode is faster, but still 2-3x
> slower than no indy at all (using JRuby's IC), and 4-5x slower than
>
ested if the inline flags are tweaked ?
>
> Also I do not understand why you have JRuby's callsites like MinusCallSite
> in the stacktrace. You should not use it if invokedynamic is enabled.
>
> Rémi
>
>> On May 20, 2011, at 1:21 PM, Charles Oliver Nutter wrote:
>&g
On Mon, May 23, 2011 at 11:05 AM, Christian Thalinger
wrote:
> I was on vacation for a couple of days but now I'm back.
>
> I looked at the inlining tree for fib_recursive and I can't see the fib_ruby
> method getting compiled. But instead I see something I've never seen before:
>
> 2949 105
On Mon, May 23, 2011 at 2:02 PM, John Rose wrote:
> Sometimes you can get your dumps faster by using -XX:-DisplayVMOutput along
> with -XX:+PrintAssembly. The output goes to hotspot.log anyway.
>
> Also, -XX:CompileCommand=print,foo::bar will focus assembly printing on the
> method(s) you care
I'm working up a set of files that show JRuby compilation output, but
I noticed a couple things that might be interesting right now.
First off, fairly early in the assembly output for fib, I see this:
0x02876d1f: call 0x0282d0e0 ; OopMap{[96]=Oop [100]=Oop
[28]=Oop [40]=Oop [48]=Oop o
nting back at fib_ruby
* permute args
* GWT
- Charlie
On Mon, May 23, 2011 at 4:19 PM, Charles Oliver Nutter
wrote:
> I'm working up a set of files that show JRuby compilation output, but
> I noticed a couple things that might be interesting right now.
>
> First off, fairly early
hings to
>> inline better?
>>
>> FWIW, the handle chain in question that's not inlining is pretty simple:
>>
>> * DMH pointing back at fib_ruby
>> * permute args
>> * GWT
>>
>> - Charlie
>>
>> On Mon, May 23, 2011 at 4:19 PM, C
inlines past this
point. Usually it would say "too big" or something.
I do see MinusCallSite inline earlier.
- Charlie
On Mon, May 23, 2011 at 4:47 PM, Charles Oliver Nutter
wrote:
> The following chunk should be the invokedynamic call to fib, via a
> GWT, an arg permuter,
e foo call inline...the foo calls themselves do
not appear in logc inlining graph at all.
- Charlie
On Mon, May 23, 2011 at 4:50 PM, Charles Oliver Nutter
wrote:
> Also, fwiw...after these two chunks in LogCompilation output, I see
> nothing else inlined into fib_ruby, including a monomorphic cal
at 4:56 PM, Charles Oliver Nutter
wrote:
> Another example, running bench/language/bench_method_dispatch_only,
> which runs a 1m iteration loop that invokes an empty "foo" method five
> times:
>
> https://gist.github.com/9008f94fc677f3fe98e7
>
> Note again that it seem
On Mon, May 23, 2011 at 5:20 PM, Tom Rodriguez wrote:
>
> On May 23, 2011, at 2:50 PM, Charles Oliver Nutter wrote:
>> I also do not see any indication *why* nothing inlines past this
>> point. Usually it would say "too big" or something.
>
> If there's no
> On Mon, May 23, 2011 at 5:20 PM, Tom Rodriguez
> wrote:
>> Actually my guess is that the selectAlternative machinery is what's screwing
>> it up. That code gets emitted as:
Same benchmark but instead of binding a direct handle via a GWT, I
force it to fail over to an inline cache immediately
On Mon, May 23, 2011 at 6:17 PM, Rémi Forax wrote:
> On 05/24/2011 12:44 AM, Tom Rodriguez wrote:
>> I haven't been following 292 that closely but it used to be a piece of code
>> that did precisely that.
>>
>> + private Object invoke_L0() throws Throwable {
>> + if ((boolean) t
ff as it stands right now is here: https://gist.github.com/987939
- Charlie
On Mon, May 23, 2011 at 7:23 PM, Tom Rodriguez wrote:
>
> On May 23, 2011, at 5:13 PM, Charles Oliver Nutter wrote:
>
>> On Mon, May 23, 2011 at 6:17 PM, Rémi Forax wrote:
>>> On 05/24/2011 12:44
On Mon, May 23, 2011 at 7:41 PM, John Rose wrote:
>> I'm still unclear why you couldn't write your own variant of guardWithTest
>> and have it work but my knowledge of what's really allowed is somewhat
>> limited.
>
> Those snippets will inline (I think), but at some point Charlie will want to
On Wed, May 25, 2011 at 12:18 AM, John Rose wrote:
> On May 23, 2011, at 5:43 PM, Charles Oliver Nutter wrote:
>
> Well I have a prototype GWT in place, but I'm having trouble getting
> invokeExact to work. As far as I can tell, incoming arguments should
> match the handle typ
On Wed, May 25, 2011 at 11:31 AM, Charles Oliver Nutter
wrote:
> Build in progress! I'll let you know how it goes. How low is low in "low
> arity"?
Ok, we're definitely back to having solid performance, but it's not as
good as it was before. I'm not
ynamic dispatch is better, but only by a tiny margin. :(
I'll start browsing logs and asm dumps later today to see if I can
figure out why it's not as fast as before.
- Charlie
On Wed, May 25, 2011 at 12:00 PM, Charles Oliver Nutter
wrote:
> On Wed, May 25, 2011 at 11:31 AM, Ch
On Wed, May 25, 2011 at 2:14 PM, John Rose wrote:
> On May 25, 2011, at 9:31 AM, Charles Oliver Nutter wrote:
>
>> Build in progress! I'll let you know how it goes. How low is low in "low
>> arity"?
>
> About 0-9.
>
> Let's find the next bottle
On Wed, May 25, 2011 at 5:12 PM, Tom Rodriguez wrote:
> I've got the bimorphic method handle inline working. I was doing something
> stupid at the beginning which is why it wasn't as easy as I expected to be
> and then I encountered a stupid API which wasted a little more time. I was
> able t
1 - 100 of 774 matches
Mail list logo
