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 OutOfMemo
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 additiona
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, 201
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
resour
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 -ign
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 w
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 going
On Oct 16, 2013, at 7:46 PM, Dmitry Nadezhin 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. Not sure what
can be d
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 wrote:
> Hi,
>
> I took a look at the patch, but i am not an expert in this area.
>
> On BigInteger:
>
>
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 * -2{@code Integer
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
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 requir
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 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
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 a
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 A
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 p
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
wrote:
> It is important that BigInteger objects be full-fledged instances on which
> all method
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 value
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 ra
21 matches
Mail list logo
