memorySegment.asByteBuffer().duplicate() causes multi-MB allocations

[Maurizio Cimadamore]

Looking at this recordings with JMC is inconclusive.

All I see is that your app seems to be using up to 20MB heap, which 
seems rather low.

The number of live objects, at least according to the tool is a handful 
(< 10).

I don't see anything here indicating a problem? (but maybe I'm looking 
in the wrong place?)

Maurizio

On 25/10/2022 15:15, Sebastian Stenzel wrote:
> Ok so here are the recordings:
>
> with duplicate(): https://static.cryptomator.org/tmp/before890035c.jfr 
> <https://urldefense.com/v3/__https://static.cryptomator.org/tmp/before890035c.jfr__;!!ACWV5N9M2RV99hQ!JDzHI5oiHSZJaLRKXbpqU6kqSKHSD0yZEIW8lQT4wRJq0M-_iS6Kz59xcSpcX_sMupZlUpzmv9uLpTNulFGUEIRVe93lmH_Uzw$>
> without: https://static.cryptomator.org/tmp/after890035c.jfr 
> <https://urldefense.com/v3/__https://static.cryptomator.org/tmp/after890035c.jfr__;!!ACWV5N9M2RV99hQ!JDzHI5oiHSZJaLRKXbpqU6kqSKHSD0yZEIW8lQT4wRJq0M-_iS6Kz59xcSpcX_sMupZlUpzmv9uLpTNulFGUEIRVe93JaaOc7g$>
>
> This is the diff in code: 
> https://github.com/cryptomator/jfuse/commit/890035c702489cdb2e094a1fc767e75b15b04891 
> <https://urldefense.com/v3/__https://github.com/cryptomator/jfuse/commit/890035c702489cdb2e094a1fc767e75b15b04891__;!!ACWV5N9M2RV99hQ!JDzHI5oiHSZJaLRKXbpqU6kqSKHSD0yZEIW8lQT4wRJq0M-_iS6Kz59xcSpcX_sMupZlUpzmv9uLpTNulFGUEIRVe92yJr55Hg$>
>
> I was testing the `read` method in this class. `write` (with its 
> `.asReadOnlyBuffer()`) did not draw my attention.
>
>> On 25. Oct 2022, at 15:03, Maurizio Cimadamore 
>> <maurizio.cimadamore at oracle.com> wrote:
>>
>> No worries.
>>
>> I guess having a look at jfr file would be useful. But note that I 
>> don't think you can send that to the mailing list - AFAIK, 
>> attachments are dropped.
>>
>> Also, forgot to ask - is this something for which you saw a 
>> difference between 18 and 19? Because that would be odd too.
>>
>> Maurizio
>>
>> On 25/10/2022 13:26, Sebastian Stenzel wrote:
>>> I can't reproduce it any longer. 😖
>>>
>>> I swear I would not have consulted the mailing list, if the 
>>> observation had not been that spooky. Especially regarding said 
>>> discrepency between `asReadOnlyBuffer()` and `duplicate()`.
>>>
>>> I still have the .jfr file, though. Is this of any use (other than 
>>> proving I'm not seeing ghosts)?
>>>
>>>> On 25. Oct 2022, at 13:15, Maurizio Cimadamore 
>>>> <maurizio.cimadamore at oracle.com> wrote:
>>>>
>>>>
>>>> On 25/10/2022 12:04, Maurizio Cimadamore wrote:
>>>>> ```
>>>>> public MappedByteBuffer duplicate() {
>>>>>         return new DirectByteBuffer(this,
>>>>>                                               this.markValue(),
>>>>>                                               this.position(),
>>>>>                                               this.limit(),
>>>>>                                               this.capacity(),
>>>>>                                               0,
>>>>>
>>>>>                                               fileDescriptor(),
>>>>>                                               isSync(),
>>>>>
>>>>>                                               segment);
>>>>>     }
>>>>> ```
>>>> Btw, the implementation of `adReadOnlyBuffer` is virtually 
>>>> identical to the above - the only difference is that 
>>>> DirectBuffer::asReadOnlyBuffer creates a new DIrectBufferR (where R 
>>>> stands for Read Only), not just another DirectBuffer. On read-only 
>>>> direct buffers (DirectBufferR), asReadOnly buffer just calls 
>>>> duplicate().
>>>>
>>>> So, I think it's very strange that one one of them misbehave, since 
>>>> the implementation is so close.
>>>>
>>>> What do you use to monitor the allocations? One theory is that 
>>>> perhaps one version of the code "escapes" better than the other, so 
>>>> the numbers you see are skewed, and in some cases you see the 
>>>> actual BB allocations on the heap, whereas in the other case you 
>>>> don't see anything because the JVM scalarizes the BB views. But 
>>>> again, the `duplicate` and `adreadOnlyBuffer` are so close to each 
>>>> other that it's hard to imagine meaningful differences in terms of 
>>>> escape analysis (even though escape analsyis can sometimes act in 
>>>> surprising ways).
>>>>
>>>> Maurizio
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20221026/d6818a2c/attachment-0001.htm>