Java OpenJDK Runtime Floating Point Alteration.

I am after a group of what could be terms Java SubSystem developers to alter and rebuild three versions of the Java runtime to address the following issues:

In the Java OpenJDK 12, floating point denormal and pronormal values result from arithmetic operations on float and double, Float and Double. The means of the floating point operations could be enhanced or replaced and rendered range accurate for the value results last decimal place. This all corresponds to the defaulting mode where the strictfp keyword is absent (strctfp mode should be left unchanged).

What I believe I am after is the floating point operations behaviour modes that Java 1.1 used to have. Maybe it will be enough, largely, to copy from those old instrinsics again, although what I am after is a change to 64 bit Java, not 32 bit.

I presently seek that Windows 64 bit, Linux 64 bit and Mac 64 bit runtimes be changed. It is my understanding that once the intrinsics involved are done for one OS version, it can be pasted over and rebuilt into the other OS versions.

I would like these floating point runtime alterations to be on a runtime done both ways: I want both a distinct runtime and a joint compiler/runtime file group for each OS platform. If not, the joint compiler and runtime kit approach can be kept together, the javac and java / javaw commands. I would, in this regards, where posible, hope for both of these options.

Direct mode arithmetic on float, double, Float, Double, alongside the version of scientific or engineering notation that can commence to be used inside these types, as well as hexadecimal mode arithmetic, accessible via 0x, likely all need updating, to keep the least decimal place correct under floating point denormal and pronormal circumstances. The related operations will be:

+, -, *, /, %, ++x , --x, x++, x--, (, ), +=, -=, *=, /=, %=.

Operand order and bracket involvement may also be part of what has to be repairs.

java.lang.StrictMath will need to be updated so that all its method calls operate with full accurate performance for the values final decimal place via all function input values. If any of StrictMath contains the strictfp keyword, those will have have to be removed and compiled out, as might be needed with inside java.lang.Math.

I am not quite sure where they presently keep the source code, resource files, and build script(s) for OpenJDK 12, yet I believe they are publically available.

It is my hope that the updated results, possessing range accurate arithmetic operations, will load and accumulate in memory systematically, so that the relevant sub operations arrange well in memory, scale well with many such java (program level) operations, and that while the total result will be slower than floating point mode, things will continue to execute quite fast enough.

In keeping with the GPL license, the source code and resource files, as well as the built product, should be uploaded to Sourceforge or very similar. Everyone involved with the development can attach their names to the project online as they wish.

**It would be very helpful if individual(s) involved can align to a GMT + 10:30 timezone and are able to, during any particularly day, take part in continuing time-aligned discussions by email. Live chats and Skyping are not really an option given other restrictions involved that cant presently be got around.

I envisage a situation where the successful applicant will not wait to the end of the postage time period for this Job task, but will be notified, email exchanged with, and commence their task as promptly as becomes feasible, using their time before deadline throughout.
About the recuiter
Member since Mar 14, 2020
Dennis Hanani
from Kerala, India

---

---

Offer to work on this project closes in 29 days!
Are you interested in this Opportunity?

Looking for help? Checkout our video tutorial
How to search and apply for jobs

How to apply? Do you have more questions about the Job?
See frequently asked questions