On Sep 8, 2011, at 5:35 PM, Thomas Wuerthinger wrote:
> The operand stack and locals manipulation in the generated bytecodes must
> exactly match the manipulations done by the scripting interpreter, but I
> think that it is possible to align those (although there might be some
> complexity due
On 09.09.2011 01:21, John Rose wrote:
On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote:
Here an example for a scripting method that performs a+b and is
guessed to not overflow.
Your example is simplified by the fact that, in the handler, there is
only one possible deopt point. What if t
If we have coroutine, yes!
Remi
John Rose wrote:
>On Sep 8, 2011, at 3:06 PM, Rémi Forax wrote:
>
>> but you can get live value unless you allow to insert live values to the
>> constant pool
>> when linking the class (another old dream).
>
>Can we make a solution from ClassValue? -- John
>
>
On Sep 8, 2011, at 3:06 PM, Rémi Forax wrote:
> but you can get live value unless you allow to insert live values to the
> constant pool
> when linking the class (another old dream).
Can we make a solution from ClassValue? -- John
___
mlvm-dev mailin
On Sep 8, 2011, at 4:06 PM, Thomas Wuerthinger wrote:
> Here an example for a scripting method that performs a+b and is guessed to
> not overflow.
Your example is simplified by the fact that, in the handler, there is only one
possible deopt point. What if there are two?
E.g., what if your cod
On 08.09.2011 21:47, John Rose wrote:
On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote:
Why not the following code pattern? Does it generate too many bytecodes?
That's a reasonable alternative.
It generates data movement bytecodes O(L * M), where L is the average
number of live values a
On 09/08/2011 01:12 AM, John Rose wrote:
> On Sep 7, 2011, at 3:28 PM, Rémi Forax wrote:
>
>> On 09/07/2011 10:38 PM, John Rose wrote:
>>>Object l0, l1, l2, ...;
>>>l0 = l1 = l2 = ... null; // these are required only for definite
>>> assignment in the catch body
>>>try {
>>> ...d
On Sep 8, 2011, at 4:57 AM, Thomas Wuerthinger wrote:
> Why not the following code pattern? Does it generate too many bytecodes?
That's a reasonable alternative.
It generates data movement bytecodes O(L * M), where L is the average number of
live values at deopt points and M is the number of d
> Should there be a relevant jdk7-b147-to-bsd-port.patch patch for the
> hotspot tree?
>
> (blush) Now there is. -- John
Cheers!
___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
On Sep 8, 2011, at 11:45 AM, Michael Barker wrote:
> Should there be a relevant jdk7-b147-to-bsd-port.patch patch for the
> hotspot tree?
(blush) Now there is. -- John___
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mai
Changeset: 6d10c6db8300
Author:jrose
Date: 2011-09-08 12:06 -0700
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/6d10c6db8300
rebase mlvm to hsx/hotspot-comp (add jdk7-b147-to-bsd-port)
+ jdk7-b147-to-bsd-port.patch
___
mlvm-dev m
Hi,
Should there be a relevant jdk7-b147-to-bsd-port.patch patch for the
hotspot tree?
stub:hotspot mikeb01$ hg qselect
bsd-port
stub:hotspot mikeb01$ head -4 .hg/patches/series
# base = a32de5085326 in
http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot [2011-09-01]
jdk7-b147-to-bsd-port.patch
On 07.09.2011 22:38, John Rose wrote:
> For example, at the Summit Remi pointed out an optimization problem
> associated with this pattern:
>
> Object l0, l1, l2, ...;
> l0 = l1 = l2 = ... null; // these are required only for definite
> assignment in the catch body
> try {
> ...do fast
13 matches
Mail list logo
