{"id":4741,"date":"2026-08-06T10:30:31","date_gmt":"2026-08-06T08:30:31","guid":{"rendered":"https:\/\/www.tutego.de\/blog\/javainsel\/?p=4741"},"modified":"2026-08-06T20:56:21","modified_gmt":"2026-08-06T18:56:21","slug":"what-actually-runs-when-you-call-math-sin-java-source-fdlibm-and-what-hotspot-does-instead","status":"publish","type":"post","link":"https:\/\/www.tutego.de\/blog\/javainsel\/2026\/08\/what-actually-runs-when-you-call-math-sin-java-source-fdlibm-and-what-hotspot-does-instead\/","title":{"rendered":"What Actually Runs When You Call Math.sin(). Java source, fdlibm, and what HotSpot does instead"},"content":{"rendered":"
\n
\n

Not every operation in a Java program has a corresponding machine instruction. Some operations can be lowered directly to hardware, while others require a software algorithm. For library methods, the API contract determines which results are acceptable, and that contract in turn determines which implementation substitutions the runtime may perform.<\/p>\n<\/div>\n

\n

1.2.1. Machine Support and Software Algorithms<\/h4>\n
\n

Programmers are used to thinking of arithmetic operations as processor operations. For basic floating-point arithmetic, that model largely holds: addition, subtraction, multiplication, and division map directly to machine instructions. Square root is the clearest further example.<\/p>\n<\/div>\n

\n

Transcendental functions break the model. Sine, cosine, exponential, logarithm, and general power are normally computed by software algorithms assembled from ordinary arithmetic. Those algorithms perform argument reduction, evaluate polynomial or table approximations, reconstruct the result, and handle special values such as NaN, infinities, and signed zero.<\/p>\n<\/div>\n

\n\n\n\n
<\/td>\n\n
\n

Historical Exception: x87<\/strong><\/p>\n<\/div>\n

\n

x86 still includes historical x87 instructions for transcendental functions, among them\u00a0FSIN<\/code>,\u00a0FCOS<\/code>,\u00a0FPTAN<\/code>, and the logarithm instruction\u00a0FYL2X<\/code>. Modern compilers and math libraries rarely use them.<\/p>\n<\/div>\n

\n

The x87 instruction set relies on an outdated stack-based register model and processes one value at a time. Its transcendental instructions also have limited accuracy.\u00a0FSIN<\/code>, for example, reduces its argument using a 66-bit approximation of \u03c0, so its precision deteriorates for large arguments and for values close to a multiple of \u03c0.<\/p>\n<\/div>\n

\n

Current implementations therefore use software algorithms built from ordinary floating-point instructions rather than the x87 transcendental instructions.<\/p>\n<\/div>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

\n

On current instruction sets, the operations relevant here fall into three groups.<\/p>\n<\/div>\n\n\n\n\n<\/colgroup>\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Table 2. Machine support for different operations<\/caption>\n
Operation<\/th>\nTypical machine support<\/th>\nHow the result is obtained<\/th>\n<\/tr>\n<\/thead>\n
\n

+<\/code>,\u00a0-<\/code>,\u00a0*<\/code>,\u00a0\/<\/code>\u00a0on\u00a0float<\/code>\u00a0and\u00a0double<\/code><\/p>\n<\/td>\n

\n

Direct<\/p>\n<\/td>\n

\n

One instruction per operation, with the rounding required by Java<\/p>\n<\/td>\n<\/tr>\n

\n

Square root (sqrt<\/code>)<\/p>\n<\/td>\n

\n

Direct<\/p>\n<\/td>\n

\n

One correctly rounded square-root instruction<\/p>\n<\/td>\n<\/tr>\n

\n

Fused multiply-add (fma<\/code>)<\/p>\n<\/td>\n

\n

Architecture-dependent<\/p>\n<\/td>\n

\n

One instruction with a single final rounding where the processor provides FMA; otherwise a software fallback<\/p>\n<\/td>\n<\/tr>\n

\n

Rounding operations (rint<\/code>,\u00a0floor<\/code>,\u00a0ceil<\/code>)<\/p>\n<\/td>\n

\n

Architecture-dependent<\/p>\n<\/td>\n

\n

Typically lowered to one or a small number of instructions on current instruction sets<\/p>\n<\/td>\n<\/tr>\n

\n

Exponential and logarithmic functions (exp<\/code>,\u00a0log<\/code>,\u00a0log10<\/code>)<\/p>\n<\/td>\n

\n

No generally used direct instruction<\/p>\n<\/td>\n

\n

Argument reduction followed by polynomial or table approximation<\/p>\n<\/td>\n<\/tr>\n

\n

General power (pow<\/code>)<\/p>\n<\/td>\n

\n

No generally used direct instruction<\/p>\n<\/td>\n

\n

Special-case handling followed by logarithm and exponential computation<\/p>\n<\/td>\n<\/tr>\n

\n

Sine, cosine, and tangent (sin<\/code>,\u00a0cos<\/code>,\u00a0tan<\/code>)<\/p>\n<\/td>\n

\n

No generally used direct instruction<\/p>\n<\/td>\n

\n

Argument reduction followed by polynomial approximation<\/p>\n<\/td>\n<\/tr>\n

\n

Inverse trigonometric functions (asin<\/code>,\u00a0acos<\/code>,\u00a0atan<\/code>,\u00a0atan2<\/code>)<\/p>\n<\/td>\n

\n

No generally used direct instruction<\/p>\n<\/td>\n

\n

Software algorithm throughout<\/p>\n<\/td>\n<\/tr>\n

\n

Hyperbolic functions (sinh<\/code>,\u00a0cosh<\/code>,\u00a0tanh<\/code>)<\/p>\n<\/td>\n

\n

No generally used direct instruction<\/p>\n<\/td>\n

\n

Software algorithms built largely on the exponential function<\/p>\n<\/td>\n<\/tr>\n

\n

Cube root and hypotenuse (cbrt<\/code>,\u00a0hypot<\/code>)<\/p>\n<\/td>\n

\n

No generally used direct instruction<\/p>\n<\/td>\n

\n

Software algorithms;\u00a0hypot(\u2026\u200b)<\/code>\u00a0scales its arguments to avoid intermediate overflow<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\n

The processor is not short of specialized instructions; they simply apply to different operations. Methods such as\u00a0Integer.bitCount(\u2026\u200b)<\/code>,\u00a0numberOfLeadingZeros(\u2026\u200b)<\/code>, and\u00a0reverseBytes(\u2026\u200b)<\/code>\u00a0can each lower to a single instruction, while\u00a0Math.sin(\u2026\u200b)<\/code>\u00a0remains a library operation.<\/p>\n<\/div>\n

\n

That difference has a cost. A floating-point multiplication takes only a few cycles, whereas a transcendental function usually requires many instructions.\u00a0Math.sin(\u2026\u200b)<\/code>\u00a0becomes more expensive still when a large argument requires the slow path of argument reduction. A machine instruction is therefore only one possible implementation mechanism. Where no suitable instruction exists, an implementation must provide an algorithm. Where an instruction does exist, the runtime may still need a fallback for platforms that do not provide it. The cost of software algorithms also gives the runtime an incentive to replace a default implementation with a faster one, but only as far as the contract of the method allows.<\/p>\n<\/div>\n<\/div>\n

\n

1.2.2. Contracts:\u00a0Math<\/code>\u00a0and\u00a0StrictMath<\/code><\/h4>\n
\n

Machine support does not determine the API contract. For the numerical library methods discussed here,\u00a0Math<\/code>\u00a0and\u00a0StrictMath<\/code>\u00a0define two different contractual models. Java once distinguished between strict and non-strict evaluation of floating-point expressions. JEP 306[1<\/a>]<\/sup>\u00a0removed that distinction in Java 17. Floating-point expressions are now always evaluated strictly, and the\u00a0strictfp<\/code>\u00a0modifier has become a no-op for which\u00a0javac<\/code>\u00a0issues a warning.<\/p>\n<\/div>\n

\n

This change did not make\u00a0Math<\/code>\u00a0and\u00a0StrictMath<\/code>\u00a0equivalent. The two mechanisms address different concerns:<\/p>\n<\/div>\n

\n