New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[Maurizio Cimadamore]

Hi Remi,

> Also taking a SegmentAllocator as parameters introduce 3 issues:
> - obviously it's not backward compatible
> - there is a problem of trust, should my code verify the return value of SegmentAllocator.allocate() or blindy trust the SegmentAllocator implementation ? And also who is responsible for zeroing (*) the segment ?
> - that interface has no explicit signal to indicate that a memory segment can be recycled, so a lot of existing memory allocators/algorithms can not be implemented.
>
> (*) BTW, zeroing is a big difference between a SegmentAllocator and an Arena but I believe it's not explicily documented in the SegmentAllocator API.
I think here we're getting too much into the specifics of FFM API. I'm 
happy to follow up on this on a more apt channel (either offline, or 
panama-dev), as I think some of the claims re. zeroing and custom 
allocators are off, but this is outside the scope of this thread.
>
>> If you really want something close to a "raw" allocation, then you can
>> create downcall method handles for "malloc" and "free" and take it from
>> there. You will get restricted warnings (as you should, since you are
>> opting out of the safety provided by arenas), but you should get
>> performance numbers that are more aligned with a raw Unsafe::allocate
>> memory.
> If your code is a library it's not really an option.

What do you mean? Because then the client would have to use the command 
line flag?

Maurizio