[foreign-jextract] RFR: MemorySegmentPool + Allocator [v8]

[Maurizio Cimadamore]

On Thu, 22 Apr 2021 09:54:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Radoslaw Smogura has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tests better distribute sizes for pseudo random allocation - now much larger buffers gets allocated and used.
>>   
>>   I'm bit puzzled here, as it looks like, that allocatioin is very fast, only
>>   reading is extreme slow.
>>   
>>   For comparision when processing single allocation:
>>   Update only first byte: direct pool access - 33ns, malloc / free: 59ns
>>   Update very 1024th byte: 12980ns, vs malloc: 8400ns
>>   
>>   I think simillar results has been spot during test with StringLen.
>
> test/micro/org/openjdk/bench/jdk/incubator/foreign/AllocatorsForLongRun.java line 162:
> 
>> 160:     for (int idx = 0; idx <  size; idx += 1024) {
>> 161: //      MemoryAccess.setByteAtOffset(s, l, (byte)0);
>> 162:       BYTE.set(s, 0, (byte) 1);
> 
> You need to cast the offset (idx?) back to a long when you call BYTE.set, otherwise the var handle invocation is not exact.

That said, IMHO, in the new benchmark, the cost of reading dominates everything else. It's not an issue with the memory access API either - replacing read with Unsafe::putInt it still slow. Honestly, since you are after measuring allocation performances, I'm not sure if `readSegment` even belongs here. The more allocations you have, with bigger sized segments, the more read will dominate anything else, to the point of rendering the benchmark not very useful to measure what you want to measure. In fact, even the `strlen` call was an issue in the previous benchmark - as the size of string grows, the time spent in copying data, and strlen grows as well, which then masks the allocation costs. Here you have a similar situation, I think.

-------------

PR: https://git.openjdk.java.net/panama-foreign/pull/509