Official support for Unsafe

[Remi Forax]

Hello mery kitty, 
""Safety"" is half of the problem here. 

The other half is the cost of maintaining an official API to do native access and the fact that it will make future features/optimizations harder or impossible (cf the work to support sun.misc.Unsafe in Valhalla). 

We already provide command line options to access to jdk.internal.misc.Unsafe (--add-exports/-add-opens) that are already too powerful IMO, but at least the contract is clear, any classes in jdk.internal.blah may change in the next JDK. 

So you can access to the extra 1% if you want, at the cost of having to track the changes of the internal classes of the JDK. That is a fair deal for me. 

regards, 
Rémi 

> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>
> Cc: "Quân Anh Mai" <anhmdq at gmail.com>, "amber-dev" <amber-dev at openjdk.org>
> Sent: Friday, January 12, 2024 6:00:58 PM
> Subject: Re: Official support for Unsafe

> Indeed, this is the whole question: how much of *everyone’s* safety are we
> willing to trade to make the already-pretty-good, 99.999% case run a little
> faster.

>> On Jan 12, 2024, at 11:52 AM, Maurizio Cimadamore < [
>> mailto:maurizio.cimadamore at oracle.com | maurizio.cimadamore at oracle.com ] >
>> wrote:

>> Heck, looking at the results of the 1brc competition, your pure Java solution
>> (no Unsafe, just FFM) ended up scoring quite high (3rd!) - at some point the
>> question has to become: how much safety I'm willing to sacrifice to get an
>> extra 1% ? I know that's a subjective decision, of course, but it's one that,
>> as a community, we need to gripple with (as that has deep repercussions on the
>> rest of the ecosystem).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20240112/84e12ca8/attachment.htm>