JDK-5100935 : No way to access the 64-bit integer multiplication of 64-bit CPUs efficiently
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-09-13
  • Updated: 2018-08-15
  • Resolved: 2016-05-20
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 9
9 b120Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description

Name: js151677			Date: 09/13/2004


A DESCRIPTION OF THE REQUEST :
64-bit CPUs like AMD Opteron can multiply two 64-bit integers and produce a 128-bit result. in Java there is currently no way to access this feature. VMs even have no way to offer this capability to an application, because there is no 128-bit type for returning the result.

JUSTIFICATION :
in the security area, asymmetric cryptography plays an important role. algorithms like RSA use long integer arithmentic extensively. for instance, certain baisc long integer operations like multiplication have quadratic running time. in this case, using a 64-bit multiplication as a basis instead of a 32-bit muliplication can decrease the number of required steps to a fourth. thus, time consuming RSA operations could be much faster just by exploiting 64-bit muliplication.
this feature could speed up the java.math.BigInteger class significantly.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the most natural thing would be to introduce a 128-bit type; e.g. long128.

CUSTOMER SUBMITTED WORKAROUND :
use 32-bit multiplication with 64-bit results. however, using this takes four times longer in an algorithm with quadratic running time.
(Incident Review ID: 310503) 
======================================================================

Comments
Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-September/035289.html Review reprise: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/041248.html
18-05-2016

I don't see this particular RFE strongly tied to value type; I think it would be helpful to provide a static method with this functionality even if an "Integer128" type is added as part of JDK 9+.
17-01-2015

Do we want to pursue these multiply{Full,High}() methods in Java 9, or would this topic be better served by waiting until support for value types is in place? Or the effort could be split across two different stages?
16-01-2015

Until we have support for value types, I would suspect we wouldn't want to return a long[] since code that wants this functionality will likely be performance-sensitive. Name alternatives to consider: For the (int, int) -> long case, "multiplyFull". For the high bits of (long, long) -> long, "multiplyHigh"
15-11-2013

Perhaps it would be logical to implement this capability by adding these methods to java.lang.Math: /** * Returns the product of the arguments allowing overflowed values within the range of {@code long}. */ public long multiplyExtended(int x, int y) {} /** * Returns the product of the arguments allowing overflowed values within double the range of {@code long}. * The returned value is of length two, with the more significant element being in the zeroth position. */ public long[] multiplyExtended(long x, long x) {}
04-11-2013

EVALUATION If a algorithm with quadratic complexity is being used, speeding up the integer multiples by a constant factor will have bounded benefit. It may be reasonable to provide a long multiply(int, int) method to at least model that machine capability. However, introducing a new primitive type into the language would be extremely complicated. The vm implementation of a class like BigInteger may or may not closely resemble the source code of the method; i.e. the vm could potentially use 64 x 64 -> 128 bit multiples even if this can't be expressed in Java source. ###@###.### 2004-09-17
17-09-2004