Subject: Implementation of strictfp semantics

From: [email-masked]
Date: Fri, 29 Oct 1999 04:57:46 +0900

All,

I had the shuJIT [1] support `strictfp' semantics.

The technique described in the proposal [2], namely,
store-reload and scale-up-and-down, is implemented.

I guess this is the first implementation to JVM or JIT. Isn't it?
I investigated compliance with strictfp of various JVMs,
but could not find any JVM supports strictfp.

In a paper [3], I'm discussing suitability of x86 (a.k.a. Intel IA-32)
for Java language specification, implementation of strictfp
and remained problems.
(Sorry, the paper is written only in Japanese.)
Some problems are interesting and remarkable, I think.
For instance:

  - `strictfp' can't remove disadvantage of x86 in performance sufficiently.
    Even in the context of not FP-strict,
    rounding precision should be adjusted according to the FP operation,
    because x86 doesn't have separated FP instructions for each precisions.
    Frequent adjustment of rounding precision may be disadvantage.

  - Java compiler (e.g.) must also support strictfp semantics, not only JVM.
    Java compiler can calculate constant expressions in source code.
    It have to give consideration to the context of the expression,
    FP-strict or not.

Thanks,

[1] "shuJIT --- JIT compiler for Sun JVM/x86",
    http://www.shudo.net/jit/

[2] Sun Microsystems,
    "Updates to the Java Language Specification
     for JDK Release 1.2 Floating Point",
    http://java.sun.com/docs/books/jls/strictfp-changes.pdf,
    1999.

[2] Numerics Working Group Java Grande Forum,
    "Improving Java for Numerical Computation",
    http://math.nist.gov/javanumerics/,
    Oct 1998.

[3] Kazuyuki SHUDO,
    "An implementation of strictfp semantics" (in Japanese),
    http://www.shudo.net/java-grandprix99/strictfp/,
    Oct 1999.

Kazuyuki SHUDO				Happy Hacking!
  Muraoka Lab., School of Sci. & Eng., Waseda Univ.
E-mail: [email-masked]
Address: Muraoka Lab., Waseda Univ.,
         3-4-1 Okubo Shinjuku-ku Tokyo 169-8555 JAPAN
TEL: +81-3-3209-5198	FAX: +81-3-3209-5198

---

From: "Joseph D. Darcy" <[email-masked]>
Date: Sun, 31 Oct 1999 23:28:08 -0800 (PST)

> I guess this is the first implementation to JVM or JIT. Isn't it?

The BulletTrain static Java compiler from NaturalBrigde
(http://www.naturalbridge.com/) also uses some version of the
techniques described in [2].

> but could not find any JVM supports strictfp.

What do you mean by this, the VMs don't recognize the keyword or they
don't properly implement the semantics?  If you mean the latter, what
problems did you find?  Of course, this is only a substantive issue
for x86 VMs; which ones did you look at?

> (Sorry, the paper is written only in Japanese.)

I would be interested in reading an English translation if one becomes
available.

>   - `strictfp' can't remove disadvantage of x86 in performance sufficiently.

Implementing strictfp as described in [2] is certainly more tractable
than using previous approaches.  However, the semantics of default
mode are what most people will use most of the time.  Default mode as
described in [2] and the slightly different default mode in [3]
certainly do allow better, more reasonable, speed than with strictfp,
but still not full speed.  To get full speed on the x86 with
reasonable semantics you need an "indigenous" type in the language.

>     because x86 doesn't have separated FP instructions for each

This is not true.  Under Sun's default mode, double computations must
be done under double rounding precision but float computations can be
done under either double precision (with store/reload for each value)
or under float precision (with store/reload only for named
quantities).  Sun's proposal is worded to allow either idiom to be
used for float computations; one technique does not have to be used
consistently.

>     Frequent adjustment of rounding precision may be disadvantage.

It would be a relatively simple dynamic programming problem for a
compiler to figure out if it would be faster to change the precision
mode to float to avoid memory traffic or leave the precision mode in
double and perform more stores/reloads.  Presumably such a computation
would need to take into account calling conventions for methods, such
as "a method is always called with rounding precision set to double."
Of course, the importance of making such a calculation depends on the
frequency of mixed-mode code, which I understand is uncommon in
practice.

>     It have to give consideration to the context of the expression,

The issue of floating point constant folding in Java has some
unexpected subtleties.  First, [2] makes clear that all literals must
still be in the regular float or double value set; that is, you can't
write a literal for a value that requires extended exponents.  Second,
the use or non-use of strictfp for constant folding only affects the
extreme values of the floating point range; as a practical matter,
very large or very small constants don't appear very often in
programs.  Third, Sun's proposal does not require consistent use of
the extended-exponent value sets; therefore, it is perfectly legal to
always constant fold using FP-strict semantics even if the expression
is in a default-FP context.

Java requires some integer constant folding but unless a "constant"
floating point expression is cast to an integer variable in certain
contexts, floating point constant folding is not mandatory.

Therefore, while floating point constant folding is certainly
complicated under Java 1.2, the complications can be avoid by either
not doing constant folding or by always constant folding under
strictfp (which, as you point out, would require strictfp semantics in
the Java -> JVM compiler).

-Joe Darcy
[email-masked]

---

From: SHUDO Kazuyuki <[email-masked]>
Date: Tue, 02 Nov 1999 19:22:35 +0900

Thanks for your useful comments.

> techniques described in [2].

I tried a demo version of the BulletTrain 1.1.2
and could confirm its compliance with strictfp semantics
by a test code (StrictfpTest.java) I provided on shuJIT page.

The static compiler seems to perform floating point operations
in strictfp context. The StrictfpTest.java doesn't show
any difference between in default context and in strictfp context.

> don't properly implement the semantics?

The latter.

To be exact, Sun's classic VM uses strictfp modifier to
determine whether a method should be inlined or not.
But all JVMs I investigated don't implement strictfp semantics properly.

> If you mean the latter, what problems did you find?

I've examined several JVMs' compiance with strictfp semantics by
the test code mentioned above (StrictfpTest.java).

> Of course, this is only a substantive issue for x86 VMs;
> which ones did you look at?

The following JVMs and JITs:

- for Win32
  - Sun JDK 1.3beta (HotSpot VM)
  - Sun JDK 1.2.2 (interpreter and Symantec JIT)
  - IBM JDK 1.1.8 (interpreter and IBM JIT)
- for Linux
  - JDK 1.2 pre-release 2 (interpreter, TYA and Inprise JIT)
  - JDK 1.1.7(v3 and v1a)
  - IBM JDK 1.1.8 (interpreter and IBM JIT)
- for FreeBSD
  - JDK 1.1.8 up to 1999/9/22 version

> I would be interested in reading an English translation if one becomes

Thanks. I'd like to notify all if it is translated to English.

> quantities).

Sorry, I mistook in previous mail.
As you said, it's incorrect that precision control is necessary
even in default context.
The paper [4] I wrote says the same as what you wrote above.

Golliver also pointed out this in a letter to me.
And he mentioned the use of SSE of PentiumIII for single.

Numbers I gave to references were wrong, sorry.

[2] Sun Microsystems,

[3] Numerics Working Group Java Grande Forum,
    "Improving Java for Numerical Computation",
    http://math.nist.gov/javanumerics/,
    Oct 1998.

[4] Kazuyuki SHUDO,

  Muraoka Lab., Grad. School of Sci. & Eng., Waseda Univ.