* 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
> is gcc 4.0 still required.
>
> That requirement hasn't changed. I don't think anyone has retried 4.2
> recently.
Does anyone know where to get binaries for gcc-4.0 on Lion? My shiny
new laptop stubbornly refuses to build 4.0 from macports.
Mike.
___
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
On 09/07/2011 01:00 PM, MacGregor, Duncan (GE Energy) wrote:
Could we do pass a method handle into this hypothetical to this
hypothetical addDetectingOverflow and allow thus allow the caller to
specify what should happen in the overflow case? Or does that still
leave too much of a problem reg
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
Could we do pass a method handle into this hypothetical to this
hypothetical addDetectingOverflow and allow thus allow the caller to
specify what should happen in the overflow case? Or does that still
leave too much of a problem regarding actually returning the values?
From: mlvm-dev-boun...@op
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
23 matches
Mail list logo
