Unsafe vs MemorySegments / Bounds checking...

[Brian S O'Neill]

What's the recommended replacement for the Unsafe class? I'm currently 
using a VarHandle trick that you recommended, but with jdk 23 it yields 
a performance regression of 6% in my tests compared to the Unsafe class.

For reference, the transform converts ValueLayout.JAVA_BYTE.varHandle() 
to a VarHandle which drops the first MemorySegment parameter and instead 
only has a long parameter which refers to a memory address from offset 0.

It looks like (again) the HotSpot inliner isn't doing enough to 
transform the code into the plain internal unsafe code. At the very 
least, I think there should be a convenience API which doesn't require 
me to apply a special transform step. The implementation could then at 
least employ the magic "force inline" annotations to ensure that there's 
no performance regressions.


On 2024-10-29 03:02 AM, Maurizio Cimadamore wrote:
> 
> On 27/10/2024 14:19, Johannes Lichtenberger wrote:
>> Hello,
>>
>> I've watched the Devoxx talk[1] from Thomas and Roy about the 1 
>> billion rows challenge. I assume Unsafe is going to be deprecated and 
>> removed at some point, but it seems for max performance it's still a 
>> good fit (of course if you know what to do). Wouldn't it be also 
>> possible to remove bounds checks from MemorySegments if you really 
>> want for instance via some JVM flag or something? Of course I know the 
>> spacial and temporal bounds checks are a feature and very nice (in 
>> most cases) :-)
> Hi,
> 
> the process for Deprecating Unsafe has already started:
> 
> https://openjdk.org/jeps/471
> 
> Re. 1brc, that was a fun challenge to watch. My general sense is that 
> results are a bit skewed towards the "extreme" - e.g. I don't think many 
> Java developers would really like to read (or write!) code that looks 
> like those in the top 10. For instance, in most instances I've seen, the 
> top 10 examples use some way to memory map a file, but they never do the 
> unmap (this is done by using a global arena) which I'm not sure will be 
> considered "good practice". If you write code like that, and peak 
> performance is your only concern, then yes, you can get into a place 
> where bound checks matter (a lot) in terms of CPU cycles. But I'm not 
> sure how well that translates to us mortals :-)
> 
> That said, note that there are at least a couple of Unsafe-less 
> solutions that get pretty close to the top spot:
> 
> https://github.com/gunnarmorling/1brc/blob/main/src/main/java/dev/ 
> morling/onebrc/CalculateAverage_gonix.java
> 
> https://github.com/gunnarmorling/1brc/blob/main/src/main/java/dev/ 
> morling/onebrc/CalculateAverage_merykitty.java
> 
> One is based on ByteBuffer, the other on MemorySegment. They do their 
> job in 3s - the top spot does it in 1.5. So... not too bad!
> 
> Maurizio
> 
>