Rémi your comment
The idea is just to propagate the type you need if you can.
So
for a = 2 <= 3, '<=' will return a RtObject but
for if (2 <= 3), '<=' will return a boolean because it's called in
an if.
Ah yes,
this is something that ST compilers do and I think is a good idea.
Basically
On 02/02/2012 04:45 AM, Mark Roos wrote:
> From Rémi
> Anyway, you can optimize the last instructions, <= should
> return a boolean
>so the sequence should be:
>
>ldc 4100
>aload 1
>indy <= (ILObject;)Z
>if_eq LABEL 1
>
> I am not sure how to han
Some nice comments from Rémi
So if one call is not inlined in
the middle of the body of the loop, then the VM will
not remove your MutableInteger.
This could be what is causing the difference in time. I have seen some
mails that indicate indy
GWT depth ( methodHandle sta
On Thu, Feb 2, 2012 at 4:47 AM, Rémi Forax wrote:
> It can be an escape analysis change.
> As far as I know, escape analysis don't work through indy call but
> if Charles see same performance as Java, escape analysis has to work ??
My comment was about using an iterator/cursor for iteration (no o
On 02/02/2012 04:45 AM, Mark Roos wrote:
> from Rémi
>
> if you know it will never escape,you should use an int directly.
>
> Well I am trying to build a Smalltalk system which has no static types so
> I have to box the ints. Since the code I showed was programmer entered I
> need to stay w
On 02/02/2012 04:45 AM, Mark Roos wrote:
> From Rémi
> Without the descriptors of invokedynamic and the code of the
> BSM, it's
>hard to tell.
>
> Yes but they have no invoke dynamics and I was just wondering if my
> indy part was causing the
> issue. Your answer told me that I s
>From Rémi
Anyway, you can optimize the last instructions, <= should return a
boolean
so the sequence should be:
ldc 4100
aload 1
indy <= (ILObject;)Z
if_eq LABEL 1
I am not sure how to handle this in a Smalltalk envrionment. All of the
objec
>From Rémi
Without the descriptors of invokedynamic and the code of the BSM,
it's
hard to tell.
Yes but they have no invoke dynamics and I was just wondering if my indy
part was causing the
issue. Your answer told me that I should be OK so that was helpful. This
same code was
>From charles
Ahh, ok, I figured it was something like that. So is your code
there
actual code, or is it what you compile the code as when you
realize
the value won't escape?
FWIW, I have done experiments with using enumerators instead of
integer loops
T
from Rémi
if you know it will never escape,you should use an int directly.
Well I am trying to build a Smalltalk system which has no static types so
I have to box the ints. Since the code I showed was programmer entered I
need to stay with the boxes.
There are cases where the compiler ge
nteger compare method
>
> I'll probably add a mutable bit to the header to protect the unwary in case
> it escapes but for now its
> a power tool.
>
> regards
> mark
>
>
>
>
>
> From: Charles Oliver Nutter
> To: Da Vinci Machine Projec
On 02/01/2012 10:44 PM, Mark Roos wrote:
> This may be a little much to ask but... These bytecodes take about
> 20ns per cycle to run on
> my 2.8 GHz mac using jdk8-B23 without TieredCompile. Does this seem
> reasonable given the number of indy calls?
> The GWT depth on the method sends is 1
>
On 02/01/2012 10:44 PM, Mark Roos wrote:
> Hi Charles
>
> Its pretty simple. All of my integers are boxed and are by definition
> immutable. However I noticed
> that many uses of integer were for loop counters and indexes where the
> integer never escapes from
> the method. So I added two prim
This may be a little much to ask but... These bytecodes take about 20ns
per cycle to run on
my 2.8 GHz mac using jdk8-B23 without TieredCompile. Does this seem
reasonable given the number of indy calls?
The GWT depth on the method sends is 1
thanks
mark
LABEL <56> LABEL 1
tter
To: Da Vinci Machine Project
Date: 02/01/2012 12:43 PM
Subject:Re: Benchmarking Smalltalk on JVM
Sent by:mlvm-dev-boun...@openjdk.java.net
On Tue, Jan 31, 2012 at 6:52 PM, Mark Roos wrote:
> For the initial JDK7 I get 400ms, moving to jdk8 b20 it drops to 117ms
(
Thanks
Adding
-XX:-TieredCompilation
made the run time consistent at 21ms. Still not as fast as b20 ( 5ms )
but faster than 7u4
which is 29ms.
mark
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/m
On Tue, Jan 31, 2012 at 6:52 PM, Mark Roos wrote:
> For the initial JDK7 I get 400ms, moving to jdk8 b20 it drops to 117ms (
> very nice).
> I then converted some constructor lookups to statics to get to 66ms.
> Then the obvious move to make an integer cache for which I used the jTalk
> range of
On Feb 1, 2012, at 9:34 AM, Rémi Forax wrote:
> On 02/01/2012 01:52 AM, Mark Roos wrote:
>> I just loaded about 250K lines of Smalltalk code into my jvm
>> implementation so now I can start
>> some real benchmarks using our application. All of this was done on a
>> Mac.
>>
>> My first try was
On 02/01/2012 01:52 AM, Mark Roos wrote:
> I just loaded about 250K lines of Smalltalk code into my jvm
> implementation so now I can start
> some real benchmarks using our application. All of this was done on a
> Mac.
>
> My first try was a object load which takes about 20 files and creates
>
I just loaded about 250K lines of Smalltalk code into my jvm
implementation so now I can start
some real benchmarks using our application. All of this was done on a
Mac.
My first try was a object load which takes about 20 files and creates a
pretty complex object set. This
takes 100 seconds i
20 matches
Mail list logo
