On Jun 21, 2011, at 3:28 AM, John Rose wrote:
> On Jun 20, 2011, at 12:17 PM, Tom Rodriguez wrote:
>
>> On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
>>
>>> On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
On Jun 17, 2011, at 5:00 PM, John Rose wrote:
> On Jun 17, 2011, at 10:21 AM, T
On 06/21/2011 09:36 AM, John Rose wrote:
On Jun 21, 2011, at 12:31 AM, Rémi Forax wrote:
Sorry Mark and Tom, I should have been more clear.
The idea is to artificially put a "never seen" flag in front of the
*last* fallback
in the GWT chain.
Yes. One way to do this is with a VM-internal co
On 06/21/2011 09:50 AM, Mark Roos wrote:
Thanks for the example Rémi
Out of curiosity why is the fallback method synchronized? Something
to do with SwitchPoints?
No, SwitchPoint primary use case is metaclass modification/alteration.
The problem is that several threads may want to update the
On 06/21/2011 05:43 AM, Mark Roos wrote:
John Rose stated
See section 5, "Case Study: Inline Caches and invokedynamic".
Thanks John, I have read that several times and it is very helpful
A small (non-megamorphic) polymorphic cache can be represented
as a cascade or decision tr
Thanks for the example Rémi
Out of curiosity why is the fallback method synchronized? Something to do
with SwitchPoints?
thanks
mark
From:
Rémi Forax
To:
mlvm-dev@openjdk.java.net
Date:
06/21/2011 12:28 AM
Subject:
Re: Inlining heuristic trouble
Sent by:
mlvm-dev-boun...@openjdk.java.net
On Jun 21, 2011, at 12:31 AM, Rémi Forax wrote:
> Sorry Mark and Tom, I should have been more clear.
> The idea is to artificially put a "never seen" flag in front of the *last*
> fallback
> in the GWT chain.
Yes. One way to do this is with a VM-internal combinator that simply notes
execution
On 06/20/2011 10:11 PM, Mark Roos wrote:
Not that I am the expert here but...
In the Smalltalk we are porting the typical call site supports only a
few actual classes. So the method look up ( which is based on the
object class )
only chooses from a small set ( mostly a single choice). This s
On 06/21/2011 12:27 AM, John Rose wrote:
> On Jun 20, 2011, at 1:11 PM, Mark Roos wrote:
>
>> So we do not have a path that can be assumed to be not taken (except the
>> last in the chain).
>>
>> Perhaps in the JVM this is a poor choice for implementation of a small
>> polymorphic inline cache.
John Rose stated
See section 5, "Case Study: Inline Caches and invokedynamic".
Thanks John, I have read that several times and it is very helpful
A small (non-megamorphic) polymorphic cache can be represented as
a cascade or decision tree of GWT combinators, probab
On Jun 20, 2011, at 12:17 PM, Tom Rodriguez wrote:
> On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
>
>> On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
>>> On Jun 17, 2011, at 5:00 PM, John Rose wrote:
>>>
On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>> Sorry, I was thinking r
On Jun 20, 2011, at 3:06 PM, Charles Oliver Nutter wrote:
> ...and as a result the inlining heuristics would behave the same as if we'd
> written the above in Java by hand. Interesting to note: currently, the first
> cached result ends up further down the list. In other words, it's a PIC that
>
On Jun 20, 2011, at 1:11 PM, Mark Roos wrote:
> So we do not have a path that can be assumed to be not taken (except the last
> in the chain).
>
> Perhaps in the JVM this is a poor choice for implementation of a small
> polymorphic inline cache. Here I defer to the real experts
Both monomor
On Mon, Jun 20, 2011 at 3:11 PM, Mark Roos wrote:
> So the basic operation is
> test if the class coming in is one we have seen before
> if yes then jump to the method
> if not then do a lookup and compile of the new method (
> this is the slow path)
>
inline cache. Here I defer to the real experts
regards
mark
From:
Tom Rodriguez
To:
Da Vinci Machine Project
Date:
06/20/2011 12:18 PM
Subject:
Re: Inlining heuristic trouble
Sent by:
mlvm-dev-boun...@openjdk.java.net
On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
> On 06/18/2011
On Jun 18, 2011, at 5:15 AM, Rémi Forax wrote:
> On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
>> On Jun 17, 2011, at 5:00 PM, John Rose wrote:
>>
>>> On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>>>
> Sorry, I was thinking recording which branch of the GWT is taken and
> storing t
On 06/18/2011 03:15 AM, Tom Rodriguez wrote:
> On Jun 17, 2011, at 5:00 PM, John Rose wrote:
>
>> On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>>
Sorry, I was thinking recording which branch of the GWT is taken and
storing them in the GWT.
Two GWTs should not share the same met
On Jun 17, 2011, at 5:00 PM, John Rose wrote:
> On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>
>>>
>>> Sorry, I was thinking recording which branch of the GWT is taken and
>>> storing them in the GWT.
>>> Two GWTs should not share the same metadata.
>>
>> This is the major problem with
On Jun 17, 2011, at 10:21 AM, Tom Rodriguez wrote:
>>
>> Sorry, I was thinking recording which branch of the GWT is taken and
>> storing them in the GWT.
>> Two GWTs should not share the same metadata.
>
> This is the major problem with GWT/selectAlternative. Previously when GWT
> was bytecod
On Jun 17, 2011, at 3:06 AM, Rémi Forax wrote:
> On 06/17/2011 11:50 AM, Christian Thalinger wrote:
>
> [...]
>
>>> I wonder if I haven't introduce a bug in my logic,
>>> there is a the boxing/unboxing of the return value of the test that
>>> should not occur.
>>> Question, does EA is also disa
On 06/17/2011 11:50 AM, Christian Thalinger wrote:
[...]
>> I wonder if I haven't introduce a bug in my logic,
>> there is a the boxing/unboxing of the return value of the test that
>> should not occur.
>> Question, does EA is also disable when MH.invokeExact is called ?
> Yes, as MH.invokeExact
On Jun 17, 2011, at 11:14 AM, Rémi Forax wrote:
> On 06/17/2011 10:58 AM, Christian Thalinger wrote:
>> On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
>>> // with the optimization
>>> [forax@localhost binary-operation]$ time java -cp .:classes PerfOpt
>>> real0m0.954s
>>> user0m1.030s
>>> s
On 06/17/2011 11:14 AM, Rémi Forax wrote:
> On 06/17/2011 10:58 AM, Christian Thalinger wrote:
>> On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
>>> // with the optimization
>>> [forax@localhost binary-operation]$ time java -cp .:classes PerfOpt
>>> real0m0.954s
>>> user0m1.030s
>>> sys
On 06/17/2011 10:58 AM, Christian Thalinger wrote:
> On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
>> // with the optimization
>> [forax@localhost binary-operation]$ time java -cp .:classes PerfOpt
>> real0m0.954s
>> user0m1.030s
>> sys0m0.087s
>>
>> // without
>> [forax@localhost bina
On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
> // with the optimization
> [forax@localhost binary-operation]$ time java -cp .:classes PerfOpt
> real0m0.954s
> user0m1.030s
> sys0m0.087s
>
> // without
> [forax@localhost binary-operation]$ time java -cp .:classes Perf
> real0m0.37
On Jun 15, 2011, at 5:48 PM, Christian Thalinger wrote:
> On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
>> I've just finished to code a sample for the cookbook that does
>> integer operation (+ and -) with overflow (to BigInteger).
>>
>> https://code.google.com/p/jsr292-cookbook/source/browse/#sv
On Jun 15, 2011, at 5:26 PM, Rémi Forax wrote:
> I've just finished to code a sample for the cookbook that does
> integer operation (+ and -) with overflow (to BigInteger).
>
> https://code.google.com/p/jsr292-cookbook/source/browse/#svn%2Ftrunk%2Fbinary-operation%2Fsrc%2Fjsr292%2Fcookbook%2Fbinop
I've just finished to code a sample for the cookbook that does
integer operation (+ and -) with overflow (to BigInteger).
https://code.google.com/p/jsr292-cookbook/source/browse/#svn%2Ftrunk%2Fbinary-operation%2Fsrc%2Fjsr292%2Fcookbook%2Fbinop
For a code like this one:
max = ...
for(i=0; ihttp://
27 matches
Mail list logo
