On 05/23/2012 07:50 PM, Jochen Theodorou wrote:
> no one helping me on the assembly analysis?
Wow, you have generated the biggest fib function I have ever seen.
About the bytecode you generate, as you said you have to remove
$getCallSiteArray() because it seems it does some side effects
so the JIT is not able to remove it.
I don't understand why when you call fib in the body of fib,
you are not able to say that the signature is (Object)I. You detect
that this is a recursive call (you don't use the same BSM)
but it seems you think that because fib can be changed
using the meta object protocol, you should type it (Object)Object.
But because you are in already fib, you already suppose that
at least the return type is int. Basically, you can change
the method fib when being in the middle of the execution of fib,
because at least one call of fib is on the stack,
the new method must have a return type which is compatible with fib.
Also, you should never use methods like
|DefaultTypeTransformation.intUnbox|
because you know that the return type is an int, you should
back-propagate it and the return type of plus should be (Object;Object)I
Now, the generated code, because of getCallSiteArray(),
your real code starts at line 168 and here you start
to box the two ints to two Integers to be able to call
NumberMath.subtract(Number,Number) which call
IntegerMath.substractImpl that unbox them.
The VM is not able to remove calls to box / unbox for j.l.Integer.
You should generate a must simpler path here.
You should never call a class like g.r.typehandling.*Math because
all of these methods takes Numbers as parameters.
You should create one simple class, with methods like this:
static int add(int left, int right) {
return left + right;
}
because it doesn't force you to do the boxing.
So you will do the boxing only if it's necessary, i.e. only
when the parameter is Object.
And to now which method you have to call, instead of
relying on getMath() you should use guardWithTest and
test only parameters that are Object.
cheers,
Rémi
>
> Am 19.05.2012 09:23, schrieb Jochen Theodorou:
>> Hi all,
>>
>> I was about to get a brand new assembly to ask some questions on the
>> list here when I installed the newest available jdk7 update 6. I ran my
>> simple Fibonacci test program and noticed that the time it took was
>> sudden 4.6s, where it was 3.5s before. This plus 1s doesn't look too god
>> to me. Has there been anything special that causes this? I mean before
>> the indy version was a little faster than our call site caching, now it
>> is a little slower. General java performance seems not to be reduced, so
>> I would assume it is special to indy.
>>
>> See http://rifers.org/paste/show/1702
>>
>> ... so now... is there sombody who can tell me why my indy version is
>> now even slower than my call site version? Sadly I am not really fit
>> enough in assembler anymore, especially the one produced by hotspot to
>> really read that output. So I have no idea what is wrong.
>>
>> Two things I should mention... the call to $getCallSiteArray is surplus,
>> yes, but that doesn't take much time. The only thing I know that really
>> takes a lot of time is the exception guard, but that I have to have
>> until I find a way to avoid it and the call site version has both as
>> well of course. They should not count as satisfying explanation.
>>
>> bye Jochen
>>
>
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
