* Roger Riggs:
to support addExact(), subtractExact(), negateExact(), multiplyExact(),
and toIntExact() for int and long primitive types.
Would it make sense to replace (x ^ r) 0 (x ^ y) = 0
in
+public static int addExact(int x, int y) {
+int r = x + y;
+if ((x ^ r) 0
Hi Florian,
On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer fwei...@bfk.de wrote:
Will Hotspot be able to optimize away the string construction on the
exception path in multiplyExact() if the exception is caught locally?
At least -XX:+OptimizeStringConcat should remove the need to construct a
Sorry for being absent from this thread so long, I just experienced
couple of days with very limited Internet access.
Actually the problem was firstly found on AIX platform, on which
sizeof(malloc(1)) without including stdlib.h will always give 4
instead of 8. The symptom was runtime
On 3 February 2012 00:11, Florian Weimer fwei...@bfk.de wrote:
Would it make sense to replace (x ^ r) 0 (x ^ y) = 0
with (x ^ y ^ r) 0?
That would not be correct. For example, it would signal overflow for -1 + 1.
Éamonn
On 3 February 2012 00:11, Florian Weimer fwei...@bfk.de wrote:
*
* Eamonn McManus:
On 3 February 2012 00:11, Florian Weimer fwei...@bfk.de wrote:
Would it make sense to replace (x ^ r) 0 (x ^ y) = 0
with (x ^ y ^ r) 0?
That would not be correct. For example, it would signal overflow for -1 + 1.
Oops. But there has to be a way to implement this using
Hi Jonathan,
Let's consider e.g.
src/share/native/sun/awt/splashscreen/java_awt_SplashScreen.c mentioned
by you below.
It #includes splashscreen_impl.h. This file #includes
splashscreen_config.h. And finally,
src/solaris/native/sun/awt/splashscreen/splashscreen_config.h #includes
the
The boolean expression can be refactored. (Only bit-31 is significant).
But it becomes pretty inscrutable.
(x ^ r) 0 (x ^ y)= 0 becomes
(x ^ r) 0 (~(x ^ y)) 0 becomes
((x ^ r) ~(x ^ y)) 0
Roger
On 02/03/2012 07:12 AM, Florian Weimer wrote:
* Eamonn McManus:
On 3 February 2012
* Roger Riggs:
The boolean expression can be refactored. (Only bit-31 is significant).
But it becomes pretty inscrutable.
(x ^ r) 0 (x ^ y)= 0 becomes
(x ^ r) 0 (~(x ^ y)) 0 becomes
((x ^ r) ~(x ^ y)) 0
That's what I got in my second attempt, too. It doesn't result in a
longer
I prefer the method naming safeAdd/safeNegate/safeMultiply (I think
they are a lot clearer), but can live with the ones proposed (which
are somewhat linked to BigInteger/BigDecimal).
I would like to see source code comments explaining why the algorithm
works in the final version in OpenJDK. Thats
On 02/03/2012 06:44 AM, Florian Weimer wrote:
* Roger Riggs:
The boolean expression can be refactored. (Only bit-31 is significant).
But it becomes pretty inscrutable.
(x ^ r) 0 (x ^ y)= 0 becomes
(x ^ r) 0 (~(x ^ y)) 0 becomes
((x ^ r) ~(x ^ y)) 0
That's what I got in my
On Feb 3, 2012, at 12:38 AM, Krystal Mok wrote:
Hi Florian,
On Fri, Feb 3, 2012 at 4:11 PM, Florian Weimer fwei...@bfk.de wrote:
Will Hotspot be able to optimize away the string construction on the
exception path in multiplyExact() if the exception is caught locally?
At least
My initial remarks:
In negateExact, the condition x == -x should be faster to evaluate than x
== Integer.MIN_VALUE and reflects the intent just as well.
In addExact and subtractExact, I would be inclined to implement the int
versions using long arithmetic, like this:
long lr = x + y;
int r =
On 3 February 2012 17:52, Eamonn McManus eam...@mcmanus.net wrote:
I agree with Stephen Colebourne that brief implementation comments would be
useful. But I disagree with his proposed further methods in Math
(increment, decrement, int+long variants), which I don't think would pull
their
On 3 February 2012 10:22, Vitaly Davidovich vita...@gmail.com wrote:
x == Integer.MIN_VALUE should be faster than x == -x as it's a cmp against a
constant whereas the latter requires negating x (that's a dependency too),
tying up a register to store the negation, and then doing the cmp.
The
Yeah my comment was more general - I didn't look at the entire context,
just wasn't sure why you thought that comparison would be faster (nevermind
that it's wrong as you mention :)).
Sent from my phone
On Feb 3, 2012 1:58 PM, Eamonn McManus eam...@mcmanus.net wrote:
On 3 February 2012 10:22,
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/
fdlibm needs to be compiled with optimization disabled, as on Linux.
Thanks
Michael.
Looks fine,
-Joe
On 2/3/2012 1:23 PM, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/
fdlibm needs to be compiled with optimization disabled, as on Linux.
Thanks
Michael.
Hi Tom,
Yes, I'm sorry for not including enough context when cc'ing.
The original discussion thread starts from [1]. The webrev is at [2].
For the string concats in multiplyExact():
* the StringBuilder doesn't escape
* it's only concatenating Strings and ints
which should meet the requirements
Looks good.
-Chris.
On 02/ 3/12 09:23 PM, Michael McMahon wrote:
Can I get the following change reviewed please?
http://cr.openjdk.java.net/~michaelm/7142617/webrev.1/
fdlibm needs to be compiled with optimization disabled, as on Linux.
Thanks
Michael.
19 matches
Mail list logo
