The updated patch is here:
http://cr.openjdk.java.net/~bpb/6910473/webrev.4/
It contains 4 new small tests - one for each bug:
6910473 BitLengthOverflow.java
8021203 DoubleValueOverflow.java
8021204 StringConstructorOverflow.java
8022780 DivisionOverflow.java
Each test catches possible
On 17/10/2013 15:59, Dmitry Nadezhin wrote:
Another solution may be to exclude the SymmetricRangeTests from
automatic test runs,
and to keep this file somewhere for manual tests runs only.
What do you think about this ?
Yes, this make sense. Also we have other examples of long-running or
The WebRev with @ignore in SymmetricRangeTests is here:
http://cr.openjdk.java.net/~bpb/6910473/webrev.3/
jtreg ignores the test with a message
test result: Error. Test ignored: hugeMemory
with default jtreg command-line;
jtreg runs it with additional switch -ignore:run.
On Fri, Oct 18, 2013
On 18/10/2013 17:24, Dmitry Nadezhin wrote:
The WebRev with @ignore in SymmetricRangeTests is here:
http://cr.openjdk.java.net/~bpb/6910473/webrev.3/
jtreg ignores the test with a message
test result: Error. Test ignored: hugeMemory
with default jtreg command-line;
jtreg runs it with additional
On Oct 16, 2013, at 7:46 PM, Dmitry Nadezhin dmitry.nadez...@gmail.com wrote:
Thank you, Paul.
I tried to combine your and Joe's suggestions in the updated WebRev:
http://cr.openjdk.java.net/~bpb/6910473/webrev.2/
Looks good.
A slight concern is that the test sets the max heap size to 8g.
On 15/10/2013 01:27, Brian Burkhalter wrote:
Ping!
This proposal could use more comments, not to mention review(s).
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html
Just to follow up on Paul's observation that the test runs with -Xmx8g.
I assume this isn't
Another solution may be to exclude the SymmetricRangeTests from automatic
test runs,
and to keep this file somewhere for manual tests runs only.
What do you think about this ?
Can this be implemented in jtreg (for example by @key hugeMemory tag) ?
On Thu, Oct 17, 2013 at 2:18 PM, Alan Bateman
I suggest to insert a line
* @ignore hugeMemory
to SymmeticRangeTests.java after the line
* @test
. The automatic run of jtreg with usual arguments fails with diagnostics
test result: Error. Test ignored: hugeMemory
. If somebody wants to run this test
he can run jtreg with additional switch
Thank you, Paul.
I tried to combine your and Joe's suggestions in the updated WebRev:
http://cr.openjdk.java.net/~bpb/6910473/webrev.2/
-Dima
On Tue, Oct 15, 2013 at 12:20 PM, Paul Sandoz paul.san...@oracle.comwrote:
Hi,
I took a look at the patch, but i am not an expert in this area.
Hi,
I took a look at the patch, but i am not an expert in this area.
On BigInteger:
99 * @implNote
100 * BigInteger constructors and operations throw {@code
ArithmeticException} when
101 * the result is out of the supported range. The supported range in JDK 8
is
102 * -2sup{@code
Ping!
This proposal could use more comments, not to mention review(s).
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html
Thanks,
Brian
On Oct 3, 2013, at 5:58 PM, Brian Burkhalter wrote:
I have reviewed this proposed change a couple of times in its current form
Without comments on the contents of the patch, a change in documented
behavior would require a ccc request.
Cheers,
-Joe
On 10/3/2013 5:58 PM, Brian Burkhalter wrote:
I have reviewed this proposed change a couple of times in its current form and
it looks good to me.
It would be good to see
I would expect as much, but that's an exercise I'd prefer to avoid at this time
if the content does not appear likely to be acceptable.
Thanks,
Brian
On Oct 7, 2013, at 3:26 PM, Joseph Darcy wrote:
Without comments on the contents of the patch, a change in documented
behavior would require
I have reviewed this proposed change a couple of times in its current form and
it looks good to me.
It would be good to see some comments about the general concept from BigInt
cognoscenti, and from (a) Reviewer(s) as concerns the @implNote addition as
well as the new ArithmeticExceptions added
Dear BigInteger experts,
Do you have comments to my previous message ?
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-September/021264.html
On Sat, Sep 21, 2013 at 8:13 AM, Dmitry Nadezhin
dmitry.nadez...@gmail.comwrote:
It is important that BigInteger objects be full-fledged
I prefer throwing exceptions on unusual conditions (e.g. overflow)
and letting the user clamp the value if they so wish. Clamping will lead
to unexpected behavior once values fall outside this range. Yes, it will
be documented, but I daresay most applications won't ever check for it
and
I see that I misused the word to clamp in this discussion.
I guess that addition with clumping means:
return x + y MIN_VALUE ? MIN_VALUE : x + y MAX_VALUE ? MAX_VALUE : x +
y;
The patch actually throws ArithmeticException on overflow:
if (x + y MIN_VALUE || x + y MAX_VALUE) throw new
Sounds good. Thanks for the clarification.
Gili
On 01/10/2013 9:25 PM, Dmitry Nadezhin wrote:
I see that I misused the word to clamp in this discussion.
I guess that addition with clumping means:
return x + y MIN_VALUE ? MIN_VALUE : x + y MAX_VALUE ? MAX_VALUE : x +
y;
The patch
It is important that BigInteger objects be full-fledged instances on which
all methods may be correctly invoked.
This bitLength bug started this discussion:
P4 JDK-6910473 : java.math.BigInteger.bitLength() may return negative int
on large numbers
https://bugs.openjdk.java.net/browse/JDK-6910473
Hello,
A quick note on this issue, before the recent work to use better
algorithms for BigInteger arithmetic operation, working with huge
numbers was impractical and thus BigInteger.bitLength misbehavior was
mostly an academic concern. With the better algorithms, exposure to
these large
This request for comment regards this issue
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6910473
BigInteger.bigLength() may return negative value for large numbers
but more importantly Dmitry's thread
http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/018345.html
What is the
21 matches
Mail list logo
