<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Hi Hans,</p>
<p>Giving some additional context, we'll occasionally get bug
reports that amount to an observation equivalent to the following:<br>
<br>
"I have two Big{Foo} variables and in a loop I assign larger and
larger values to them. As the values get large,
bigFoo1.add(bigFoo2) runs much faster than
bigFoo1.multiply(bigFoo2). This seems wrong."</p>
<p>With additional knowledge of the algorithmic complexities of add
and multiply for large values, the above is not a surprising
result and the intention of the note is to share some additional
context with the reader so they are not surprised by this result
either. Additionally, the note does describe what the JDK
implementation has done for some time, switching between
algorithms based in input size, etc.</p>
<p>The new text in both classes appears under an apiNote, which
means the next text is informative without being normative.
Therefore, the JDK is not obliged to behave in the described way,
but is free to do so.<br>
</p>
<p>The current BigInteger implementation is not written to be
hardened against timing side-channel measurements.</p>
<p>Thanks,<br>
</p>
<p>-Joe<br>
</p>
<div class="moz-cite-prefix">On 10/23/2023 10:19 AM, Hans Boehm
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CAMOCf+iCgvc_rTCM1KWKt4tx_0pmtMa9_f2C=K72EfHKF3NUpw@mail.gmail.com">
<div dir="ltr">Since I think this is about asymptotic complexity,
which is determined by behavior on large inputs, is there a
reason to talk about switching to other algorithms on smaller
inputs? We certainly don't want to get into the habit of listing
"easy case" optimizations everywhere.
<div><br>
</div>
<div>I'm unclear about the extent to which BigInteger is
intended to provide running times that depend only on the size
of the inputs, or whether they can vary with the actual bits
in the input. Though hard to state precisely, this does seem
to matter to cryptographers. And it sometimes seems to matter
to others, since guarantees aimed at cryptographers can slow
down other code. Is it worth stating something more in this
area?</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Oct 21, 2023 at
2:14 AM Alan Bateman <<a href="mailto:alanb@openjdk.org" moz-do-not-send="true" class="moz-txt-link-freetext">alanb@openjdk.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
Sat, 21 Oct 2023 00:56:21 GMT, Joe Darcy <<a href="mailto:darcy@openjdk.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">darcy@openjdk.org</a>>
wrote:<br>
<br>
> Add informative notes to BigInteger and BigDecimal about
possible running times, etc.<br>
<br>
The wording looks okay to me and I expect it will appear as an
API note in BigInteger.<br>
<br>
However, for BigDecimal I suspect the h2 headings (for the
next heading and the existing heading for IEEE 754 Decimal
Arithmetic) means they won't look like they are part of the
API note, instead they will look like new sections after the
API note. Do you see what I mean in the generated javadoc?<br>
<br>
-------------<br>
<br>
Marked as reviewed by alanb (Reviewer).<br>
<br>
PR Review: <a href="https://git.openjdk.org/jdk/pull/16298#pullrequestreview-1691219200" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://git.openjdk.org/jdk/pull/16298#pullrequestreview-1691219200</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>