MemorySegment off-heap usage and GC

[Maurizio Cimadamore]

Do you have evidence that on-heap usage has gotten worse in the rewrite? 
Let's leave aside the cryptic GC failures, as I don't think they have 
directly anything to do with memory segment (given you said you are not 
using JNI nor FFM - maybe some library you depend on is... hard to say).

I suspect it's probably hard to say if on-heap is better or worse, given 
that before the DB storage was on-heap, and now it's off-heap. But if 
the storage is off-heap, why is there 4GB on-heap data?

Anyway, my suggestion is to keep chipping away at the problem (not now, 
when you have the time and energy of course!) until you can e.g. 
reproduce what you are seeing with something a bit simpler than the full 
application. When we get there, we'd probably be in a better position to 
help. At this point in times there seem to be too many variables that 
are influencing the discussion, and it's not clear to me that going down 
the "memory segment is the culprit" route will be helpful. The rewrite 
clearly did something (bad) to the overall performance of the 
application - but I don't think you have 4GB of small segment wrappers 
around heap arrays (or, if that's the case, you have bigger problems 
going on :-) ).

I'm also not 100% sure that the assumption: there's more GC activity, so 
that is the explanation of the 3x slowdown is valid (again, we need a 
smoking gun). Sometimes you get more GC, but that doesn't affect things 
too much - because a lot of the objects are short-lived and 
allocation/deallocation in the TLAB is so cheap. Also, by moving data 
off-heap you should have (at least in principle) have reduced the load 
on the GC somewhat.

Maurizio

On 16/09/2024 21:40, Johannes Lichtenberger wrote:
> It stays at 4Gb max (I've configured 8Gb max, so this should be OK, 
> but always Evacuation Failure GCs). Currently I don't have the energy 
> to look further into it due to a cold, but I could upload the 3,8Gb 
> JSON file somewhere if needed for the test to run, if that helps...
>
> Am Mo., 16. Sept. 2024 um 19:03 Uhr schrieb Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com>:
>
>
>     On 16/09/2024 17:49, Johannes Lichtenberger wrote:
>     > but I thought it shouldn't be that runtime for shredding a resource
>     > (impirting JSON data) suddenly is 3x worse even now in the
>     middle of a
>     > bigger refactoring in my spare time
>
>     Ok, so there's a new bullet:
>
>     * the _execution time_ (e.g. throughput) with the memory segment
>     version
>     is now 3x slower than w/o memory segment
>
>     What does the memory usage look like? I understand that you see
>     issues
>     with GC failures due to "pinning" - but does the overall heap
>     usage seem
>     ok? Or has heap usage also increased?
>
>     Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/panama-dev/attachments/20240916/b43ba8bf/attachment.htm>