On Sep 14, 2011, at 3:05 PM, Thomas Wuerthinger wrote:
> But one could maybe disable the local variable liveness maps
> for the methods that use this functionality (i.e., the extended
> exception stack trace or the getLocalArray)?
Yes, of course. But this will increase spilling throughout thos
On 9/14/11 10:20 PM, Tom Rodriguez wrote:
> On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote:
>
>> On 13.09.2011 00:59, John Rose wrote:
>>> This exposes the question of liveness: JVMs routinely nullify
>>> non-live variables, but what if the only remaining use is the
>>> getLocalArray intri
On Sep 14, 2011, at 10:10 AM, Thomas Wuerthinger wrote:
> On 13.09.2011 00:59, John Rose wrote:
>> This exposes the question of liveness: JVMs routinely nullify
>> non-live variables, but what if the only remaining use is the
>> getLocalArray intrinsic? Shouldn't it count as a weak reference?
>From Thomas
(e.g., they could
use the Java expression stack as their own expression stack
implementation).
I believe that this is both used and necessary to create reasonable
performance implementation
of Smalltalk on the jvm. I do this in Rtalk today mapping the Smalltalk
st
On 13.09.2011 00:59, John Rose wrote:
> This exposes the question of liveness: JVMs routinely nullify
> non-live variables, but what if the only remaining use is the
> getLocalArray intrinsic? Shouldn't it count as a weak reference? Or
> will we allow it to "reanimate" all local values? That
On Sep 12, 2011, at 10:23 AM, Thomas Wuerthinger wrote:
> If this special exception class is declared as a checked exception, a method
> would itself chose if its stack is exposed or not based on its "throws"
> clause. I think in that case the possible exploitations are less than
> reflection (
On 09.09.2011 03:00, John Rose wrote:
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
the
I've taken the time to write a small prototype (by hand :( )
see http://www-igm.univ-mlv.fr/~forax/tmp/jsr292-deopt.zip
using Fibonacci as John suggest.
The idea is to transfer the control from fibo written using
ints to fibo written using Object (BigInteger at runtime).
If an operation overflow,
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
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
* John Rose [2011-09-06 20:04] writes:
> On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote:
>
> Did we ever figure out if it's possible to trick Hotspot into doing a
> JO instead of the raw bit-level operations? John/Christian/Tom: what
> would it take to get HS to "know" that we
It would be really nice if you could have a class that was something like
Double with overflow check initially and then when you detect an overflow
substitute in something like BigDecimal instead, i.e. hot swapping of the
object's class. This saves having to have a class with two fields and
checkin
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 {
>> ...do fast path...
>> if (...constraint violated..
On 09/07/2011 03:02 PM, Rémi Forax wrote:
> On 09/07/2011 09:32 PM, Per Bothner wrote:
>> On 09/07/2011 02:15 AM, Rémi Forax wrote:
>>> What about having 10 to 12 benchs, one by language, provided by each
>>> language runtime developer
>>> as a good bench for their runtime ?
>> Well, there are the
On 09/07/2011 02:25 PM, Charles Oliver Nutter wrote:
> On Wed, Sep 7, 2011 at 2:00 AM, Per Bothner wrote:
>> Kawa's gnu.math.IntNum already does this. It has only two fields:
>
> Yeah, I think I remember you mentioning this in one of the
> arbitrary-precision math threads on JVM-L. I assume you c
On 09/07/2011 10:38 PM, John Rose wrote:
On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote:
This would probably also mean that the exception object created for
capturing the slow-case program state needs to be escape-analyzed and
removed in the optimized code that deoptimizes on overflow?
On 09/07/2011 09:32 PM, Per Bothner wrote:
> On 09/07/2011 02:15 AM, Rémi Forax wrote:
>> This remember me that we don't have any benchmarks using dynamic languages
>> which is, as you explain, not good on the long term.
>>
>> What about having 10 to 12 benchs, one by language, provided by each
>>
On Wed, Sep 7, 2011 at 2:00 AM, Per Bothner wrote:
> Kawa's gnu.math.IntNum already does this. It has only two fields:
Yeah, I think I remember you mentioning this in one of the
arbitrary-precision math threads on JVM-L. I assume you could use an
intrinsic optimization for overflow checks too, y
On Sep 7, 2011, at 12:33 PM, Thomas Wuerthinger wrote:
> This would probably also mean that the exception object created for capturing
> the slow-case program state needs to be escape-analyzed and removed in the
> optimized code that deoptimizes on overflow?
Yes. And in the case of user-define
Rémi Forax wrote:
>
> so the VM knows that only methods *DetectingOverflow are able to
> throw that specific exception.
> int addDetectingOverflow(int x, int y) throws IntegerOverflowException
> This also have the advantage that the inlining heuristic can be tweaked
> to not count exception handl
On 09/07/2011 02:15 AM, Rémi Forax wrote:
> This remember me that we don't have any benchmarks using dynamic languages
> which is, as you explain, not good on the long term.
>
> What about having 10 to 12 benchs, one by language, provided by each
> language runtime developer
> as a good bench for t
On 9/7/11 1:10 AM, John Rose wrote:
That's true, except that exceptions tend to be imprecise: It's hard
to tell which sub-expression cause the exception, out of a complex
statement.
Addressing both the precision and pre-allocation problems, you could
ask the application to create the excep
On Sep 7, 2011, at 7:24 AM, Rémi Forax wrote:
> so the VM knows that only methods *DetectingOverflow are able to throw that
> specific exception.
> int addDetectingOverflow(int x, int y) throws IntegerOverflowException
> This also have the advantage that the inlining heuristic can be tweaked
> to
On 09/07/2011 05:07 AM, Charles Oliver Nutter wrote:
On Tue, Sep 6, 2011 at 6:10 PM, John Rose wrote:
> Yes. Your request for "JO" makes me think some users would be happy with a
> boolean test, a la addWouldOverflow.
> It's what happens after the test that differs widely among applications
On Sep 7, 2011, at 4:13 PM, Rémi Forax wrote:
> On 09/07/2011 01:22 PM, Christian Thalinger wrote:
>>
>>
>> On Sep 7, 2011, at 11:15 AM, Rémi Forax wrote:
>>
>>> On 09/07/2011 09:08 AM, John Rose wrote:
On Sep 7, 2011, at 12:00 AM, Per Bothner wrote:
> I assume this is one
On 09/07/2011 01:22 PM, Christian Thalinger wrote:
On Sep 7, 2011, at 11:15 AM, Rémi Forax wrote:
On 09/07/2011 09:08 AM, John Rose wrote:
On Sep 7, 2011, at 12:00 AM, Per Bothner wrote:
I assume this is one reason why Kawa's IntNum is (mostly) faster than
BigInteger.
Yes, that's probably
Rose
*Sent:* 06 September 2011 21:05
*To:* Da Vinci Machine Project
*Subject:* Re: Hotspot loves PHP.reboot
On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote:
Did we ever figure out if it's possible to trick Hotspot into doing a
JO instead of the raw bit-level operations? John/Chr
On Sep 7, 2011, at 11:15 AM, Rémi Forax wrote:
> On 09/07/2011 09:08 AM, John Rose wrote:
>>
>> On Sep 7, 2011, at 12:00 AM, Per Bothner wrote:
>>
>>> I assume this is one reason why Kawa's IntNum is (mostly) faster than
>>> BigInteger.
>>
>> Yes, that's probably true.
>>
>> Here's a dirty s
...@openjdk.java.net
[mailto:mlvm-dev-boun...@openjdk.java.net] On Behalf Of John Rose
Sent: 06 September 2011 21:05
To: Da Vinci Machine Project
Subject: Re: Hotspot loves PHP.reboot
On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote:
Did we ever figure out if it's possible to
On 09/07/2011 09:08 AM, John Rose wrote:
On Sep 7, 2011, at 12:00 AM, Per Bothner wrote:
I assume this is one reason why Kawa's IntNum is (mostly) faster than
BigInteger.
Yes, that's probably true.
Here's a dirty secret: As you can see from the OpenJDK sources,
BigDecimal, but not BigInteg
On Sep 7, 2011, at 12:00 AM, Per Bothner wrote:
> I assume this is one reason why Kawa's IntNum is (mostly) faster than
> BigInteger.
Yes, that's probably true.
Here's a dirty secret: As you can see from the OpenJDK sources, BigDecimal,
but not BigInteger, has this optimization (see private f
On 09/06/2011 08:07 PM, Charles Oliver Nutter wrote:
> I also thought of an existing API that would benefit from this, and
> perhaps there's a path to getting something in JDK 7 (unofficially)
> and JDK 8 (officially): BigInteger. Ideally BigInteger should only use
> a primitive long (or int?) up t
On Tue, Sep 6, 2011 at 6:10 PM, John Rose wrote:
> Yes. Your request for "JO" makes me think some users would be happy with a
> boolean test, a la addWouldOverflow.
> It's what happens after the test that differs widely among applications, so
> why not just standardize the test.
> if (addWouldO
On Sep 6, 2011, at 1:18 PM, Charles Oliver Nutter wrote:
> On Tue, Sep 6, 2011 at 3:04 PM, John Rose wrote:
>> (1) Write a compelling API for something like Integer.addDetectingOverflow.
>> (2) Roll it into JDK 8+epsilon.
>> (3) Do the JIT work.
>> People have thought on and off about (1) for man
On Tue, Sep 6, 2011 at 3:36 PM, Rémi Forax wrote:
> An exception is perhaps more easier to use,
> because if it overflow you may have to deoptimize, for that you need the
> stack and local values,
> it's easier to jump to a exception handler that will push all these values
> and call the interpret
On 09/06/2011 10:19 PM, John Rose wrote:
On Sep 6, 2011, at 12:58 PM, John Rose wrote:
What's needed here is a way to get 33 bits out of a 32-bit add
intrinsic. There's no fully natural way to do this, and about 4
kludgey ways. Because there are so many poor ways to shape the API,
it's hard
On Sep 6, 2011, at 12:58 PM, John Rose wrote:
> What's needed here is a way to get 33 bits out of a 32-bit add intrinsic.
> There's no fully natural way to do this, and about 4 kludgey ways. Because
> there are so many poor ways to shape the API, it's hard to pick the best one
> to invest in.
On Tue, Sep 6, 2011 at 3:04 PM, John Rose wrote:
> (1) Write a compelling API for something like Integer.addDetectingOverflow.
> (2) Roll it into JDK 8+epsilon.
> (3) Do the JIT work.
> People have thought on and off about (1) for many years, but with no clear
> winner. Exceptions or boxed object
On Sep 6, 2011, at 8:51 AM, Charles Oliver Nutter wrote:
> Did we ever figure out if it's possible to trick Hotspot into doing a
> JO instead of the raw bit-level operations? John/Christian/Tom: what
> would it take to get HS to "know" that we're doing an integer
> overflow-after-maths check and d
On Sep 6, 2011, at 11:28 AM, Charles Oliver Nutter wrote:
> On Tue, Sep 6, 2011 at 12:36 PM, Rémi Forax wrote:
>> If you have specialize for -2/+2, you should reuse exactly the same code
>> for +n/-n.
>> see
>> https://code.google.com/p/jsr292-cookbook/source/browse/trunk/binary-operation/src/jsr
On Tue, Sep 6, 2011 at 12:36 PM, Rémi Forax wrote:
> If you have specialize for -2/+2, you should reuse exactly the same code
> for +n/-n.
> see
> https://code.google.com/p/jsr292-cookbook/source/browse/trunk/binary-operation/src/jsr292/cookbook/binop/RT.java#11
You're right. I'll make that chang
On Tue, Sep 6, 2011 at 12:33 PM, Christian Thalinger
wrote:
> We already talked a bit about that some while ago. I think matching that
> double-xor-trick (or whatever it's called) is too risky. A JDK method that
> does the check (and the math?) would be nice so we can intrinsify it. GWT
> wo
On 09/06/2011 05:51 PM, Charles Oliver Nutter wrote:
> On Tue, Sep 6, 2011 at 10:39 AM, Rémi Forax wrote:
>> Yes, but don't forget that PHP.reboot has no overflow check.
> Did we ever figure out if it's possible to trick Hotspot into doing a
> JO instead of the raw bit-level operations? John/Chris
On 09/06/2011 07:33 PM, Christian Thalinger wrote:
> On Sep 6, 2011, at 5:51 PM, Charles Oliver Nutter wrote:
>
>> On Tue, Sep 6, 2011 at 10:39 AM, Rémi Forax wrote:
>>> Yes, but don't forget that PHP.reboot has no overflow check.
>> Did we ever figure out if it's possible to trick Hotspot into do
On Sep 6, 2011, at 5:51 PM, Charles Oliver Nutter wrote:
> On Tue, Sep 6, 2011 at 10:39 AM, Rémi Forax wrote:
>> Yes, but don't forget that PHP.reboot has no overflow check.
>
> Did we ever figure out if it's possible to trick Hotspot into doing a
> JO instead of the raw bit-level operations? J
On Tue, Sep 6, 2011 at 10:39 AM, Rémi Forax wrote:
> Yes, but don't forget that PHP.reboot has no overflow check.
Did we ever figure out if it's possible to trick Hotspot into doing a
JO instead of the raw bit-level operations? John/Christian/Tom: what
would it take to get HS to "know" that we're
On 09/06/2011 04:59 PM, Charles Oliver Nutter wrote:
> Awesome numbers, especially promising for impls like JRuby that will
> never have type annotations and for which type inference will be very
> limited. Getting within 3x Java while still fully boxed is amazing.
Yes, but don't forget that PHP.r
Awesome numbers, especially promising for impls like JRuby that will
never have type annotations and for which type inference will be very
limited. Getting within 3x Java while still fully boxed is amazing.
Perhaps the next big thing for InDy will be getting EA working across
invokedynamic boundar
On 09/05/2011 12:22 PM, Christian Thalinger wrote:
> On Sep 5, 2011, at 1:11 AM, Rémi Forax wrote:
>
>> I've just compiled the hotspot (64bits server) using the hotspot-comp
>> workspace of hotspot express (hsx)
>> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/
>>
>> Here are the result whe
On Sep 5, 2011, at 1:11 AM, Rémi Forax wrote:
> I've just compiled the hotspot (64bits server) using the hotspot-comp
> workspace of hotspot express (hsx)
> http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/
>
> Here are the result when running PHP.reboot on fibonacci
> (-server is the server
57 matches
Mail list logo
