P4
The number of intrinsics in the Unsafe API has grown very large.
As a result, it is difficult to evolve and maintain that API.
There are about 142 intrinsics. The bulk of these are trivial variations of each other.
For example, associated with `getInt` are four other intrinsics corresponding to memory orders other than the plain default used to load Java variables from the heap.
Multiply that by the number of types (9), and you have 45 intrinsics. Double that to add putters.
Also add various forms of compare-and-set (some weak, some with memory orders), plus compare-and-swap, plus compare-and-add, also for a range of types.
The bulk of the intrinsics are just mechanical variations on a few simple themes.
This complexity affects the interface between the JDK (in its lowest layers) and the VM (especially the JITs). The vmIntrinsic::ID type has an item for each of these intrinsics.
All these combinations can be folded down into a very small number of intrinsics, if the intrinsics are made capable of handling all the variations in one API point. This can be done by parameterizing the memory order and the type. Such an all-in-one intrinsics (say, for "Unsafe get") may be called "polymorphic" (or "generic") since it contains a family of distinct forms.
Note that both the C1 and C2 JITs expand intrinsics as if they were polymorphic. That is, there is only one IR generation point for "Unsafe get" regardless of memory order and type. So reorganizing the layer above the JIT (Unsafe) to follow that structure, with polymorphic intrinsics, will simplify the connection between the JDK and the JITs.
https://github.com/openjdk/jdk/pull/28940
As a result, it is difficult to evolve and maintain that API.
There are about 142 intrinsics. The bulk of these are trivial variations of each other.
For example, associated with `getInt` are four other intrinsics corresponding to memory orders other than the plain default used to load Java variables from the heap.
Multiply that by the number of types (9), and you have 45 intrinsics. Double that to add putters.
Also add various forms of compare-and-set (some weak, some with memory orders), plus compare-and-swap, plus compare-and-add, also for a range of types.
The bulk of the intrinsics are just mechanical variations on a few simple themes.
This complexity affects the interface between the JDK (in its lowest layers) and the VM (especially the JITs). The vmIntrinsic::ID type has an item for each of these intrinsics.
All these combinations can be folded down into a very small number of intrinsics, if the intrinsics are made capable of handling all the variations in one API point. This can be done by parameterizing the memory order and the type. Such an all-in-one intrinsics (say, for "Unsafe get") may be called "polymorphic" (or "generic") since it contains a family of distinct forms.
Note that both the C1 and C2 JITs expand intrinsics as if they were polymorphic. That is, there is only one IR generation point for "Unsafe get" regardless of memory order and type. So reorganizing the layer above the JIT (Unsafe) to follow that structure, with polymorphic intrinsics, will simplify the connection between the JDK and the JITs.
https://github.com/openjdk/jdk/pull/28940