[jira] [Comment Edited] (ARTEMIS-3444) Paging cache entries are not evicted although eligible for GC

["Francesco Nigro (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/ARTEMIS-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17404639#comment-17404639 ] 

Francesco Nigro edited comment on ARTEMIS-3444 at 8/25/21, 5:56 PM:
--------------------------------------------------------------------

If the map methods are not called anymore, no processQueue calls happen and despite OOM approaching, the soft references won't be removed from the map.
Soft references are not that automatic as we need hence is probably not th right tool for the job or we should perform background removal (Netty does the same).
I agree that mybe it's time to change how this cache work and just avoid soft references usage at all, that's why I have marked this has an improvement and not as a bug :)
We can speak tomorrow about it


was (Author: nigrofranz):
If the map is not used, no processQueue calls happen and despite OOM approaching, the soft references won't be removed from the map.
Soft references are not that automatic as we need hence is probably not th right tool for the job or we should perform background removal (Netty does the same).
I agree that mybe it's time to change how this cache work and just avoid soft references usage at all, that's why I have marked this has an improvement and not as a bug :)
We can speak tomorrow about it

> Paging cache entries are not evicted although eligible for GC
> -------------------------------------------------------------
>
>                 Key: ARTEMIS-3444
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-3444
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Francesco Nigro
>            Assignee: Francesco Nigro
>            Priority: Minor
>
> Artemis Paging cache is using {{SoftValueLongObjectHashMap}} to collect page cache entries, that's using a [ReferenceQueue|https://docs.oracle.com/javase/8/docs/api/java/lang/ref/ReferenceQueue.html] to track values eligible for GC.
> Soft references become eligible to be collected by JVM according to {{-XX:SoftRefLRUPolicyMSPerMB}} configuration and it affects when broker can remove such entries from the mentioned {{SoftValueLongObjectHashMap}} too, after offering them in the mentioned [ReferenceQueue|https://docs.oracle.com/javase/8/docs/api/java/lang/ref/ReferenceQueue.html].
> The mechanism that allow broker to remove any pending memory is by processing the ref queue filled by the JVM, but it is triggered just if there's any interaction with the page cache (size/put/remove/get/iteration), meaning that if there are no interactions, the broker won't remove such entries and the related reference queue will grow larger and larger, further occupying memory (and likely GC resources).
> The paging cache should be able to remove such entries as soon as the JVM enqueue them on the map ref queue, instead and this could be achieved by allowing background processing of evicted soft refs.
>  
> Given that [ReferenceQueue|https://docs.oracle.com/javase/8/docs/api/java/lang/ref/ReferenceQueue.html] expose timed thread-safe remove methods that could be called in background, we can considerusing a scheduled executor to monitor to remove evicted entries.
> It's key to manage concurrency of such remove operations while interacting with the map
> ie map put has created a soft ref that's immediately offered to the ref q and it's going to be removed *before* put complete, risking to "resurrect" it.
> An additional optimization could be to use a single shared reference queue, to allow using a single thread to perform the removal and (hence having the chance to issue parallel map removal requests for to the related {{PageCursorProviderImpl}}).



--
This message was sent by Atlassian Jira
(v8.3.4#803005)