Is it possible to add some parameters for automatic cache release from idle tabs in oxygen xml editor and a button

[galanohan]

Hi,

Is it possible to add a feature that, when the occupied memory of an application reaches a threshold (make it a paramter), for example, 90% of the total memory this application can consume (for example, 4000MB, the parameter could be maxMem), then release the cache of threads that have been idle for more than x minutes (this parameter can be named as idleDuration or something similar). Also, add a button that allows users to release the cache manually.

The func spec could be something like follows:

Function Name: ReleaseIdleCache

Parameters:
- maxMem: The maximum memory that the application can consume (in MB).
- idleDuration: The duration in minutes after which a thread is considered idle.

Return Type: None

Description:
This function monitors the occupied memory of an application and releases the cache of threads that have been idle for more than a specified duration. The function takes two parameters: `maxMem` and `idleDuration`. When the occupied memory reaches a threshold (e.g., 90% of `maxMem`), the function identifies the idle threads based on the `idleDuration` and releases their cache. Additionally, users can manually trigger the cache release by calling a separate function. (see Function Name: ManualCacheRelease)

Algorithm:
1. Retrieve the current occupied memory of the application.
2. Calculate the memory threshold by multiplying `maxMem` with 0.9.
3. If the occupied memory exceeds the threshold:
- Retrieve the list of threads and their respective last activity timestamps.
- Iterate through each thread:
- If the difference between the current timestamp and the last activity timestamp is greater than or equal to `idleDuration`, release the thread's cache.
4. Return from the function.

Function Name: ManualCacheRelease

Parameters: None

Return Type: None

Description:
This function allows users to manually release the cache of idle threads. When called, it identifies the idle threads based on a specified duration and releases their cache.

Algorithm:
1. Retrieve the list of threads and their respective last activity timestamps.
2. Iterate through each thread:
- If the difference between the current timestamp and the last activity timestamp is greater than or equal to a specified duration, release the thread's cache.
3. Return from the function.


--------------------------
Background:

As for as I observed, the max memory that oXygen v25.1 (without modifying default settings) can consume on my machine is 4000MB. When I open multiple tabs for various dita topics and maps, the memory could reach 4000MB very easily. For those opened and saved topics that have been idle for like minutes, the oxygen application does not release the cache, thus, oxygen v25.1 is more likely to hang when the occupied memory reaches 4000MB, for example, 3997/4000MB at the bottom right corner.

Here's my machine's specs:

Device name pollos-hermano
Processor Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz 2.90 GHz
Installed RAM 32.0 GB
System type 64-bit operating system, x64-based processor
Edition Windows 11 Pro Insider Preview
Version 22H2
Installed on ‎2023/‎10/‎31
OS build 23575.1001
Experience Windows Feature Experience Pack 1000.23575.1001.0

I think the RAM is big enough to run the oxygen but if the memory consumption mechanism doesn't change, even if I modify the maxMem of oxygen at somewhere and make it like 16 GB, similar issue could still occur...

[adrian]

Hi,

I've logged your suggestion on our issue tracking tool. For future reference it is issue EXM-53889.
Oxygen already has what we call "lazy editors", editors whose content has not been loaded, even though they were left opened since the previous session. By design these are only loaded when they become active. I guess we could unload an editor if it has been idle for a long time and turn it into a lazy editor (will be reloaded when activated).
I would also like to point out that the reality of Oxygen memory usage is somewhat different than what you have deduced. Depending on use case, editors aren't necessarily the most memory consuming components. There are output/result panels that can consume a lot of memory, if none are closed and there are many operations that have a very large memory usage spike.

As for as I observed, the max memory that oXygen v25.1 (without modifying default settings) can consume on my machine is 4000MB. When I open multiple tabs for various dita topics and maps, the memory could reach 4000MB very easily. For those opened and saved topics that have been idle for like minutes, the oxygen application does not release the cache, thus, oxygen v25.1 is more likely to hang when the occupied memory reaches 4000MB, for example, 3997/4000MB at the bottom right corner.

Actually what you see at the bottom right corner is the Java heap memory usage. While that may look worrisome, it does not reflect the reality of active memory usage. To clarify, Java has a lazy memory management and the memory is cleaned up by a garbage collector only when absolutely necessary (when it runs out of free memory). This means that it will always prefer to allocate memory if more is available, rather than cleaning up after itself. In practice this means that after intensive memory operations it would appear as if the entire heap memory has remained in use (e.g. 3997/4000MB) even though it's mostly filled with garbage data that can be cleared.

So, the memory usage you see at the bottom right corner is deceiving. What you see there is the entire used heap memory of the Java VM that Oxygen runs on including garbage/unused data). That's just the peak usage.
Clicking the garbage can icon ("Free unused memory") from the bottom right corner manually triggers a Java VM garbage collection which should discard most garbage data that uses heap memory. After doing that, you should see a value that's closer to the real active memory usage.
You will of course ask, why doesn't Oxygen already do this automatically from time to time and the answer is because it's not necessary, this already happens automatically when the Java VM decides it is required. You will note that the garbage collection also triggers CPU usage, hence the reason it is done only when absolutely necessary.

Regards,
Adrian

[galanohan]

Clicking the garbage can icon ("Free unused memory") from the bottom right corner manually triggers a Java VM garbage collection which should discard most garbage data that uses heap memory

Hi Adrian,

Thanks for explaining the memory mechanism and strategy in the backend. I noticed the garbage can icon at the bottom right corner for a long time, it's quite useful when the memory consumption bar near it remains the blue color, in such status, closing output consoles and message boxes then clicking the garbage icon will release some cache. However, it may mal-function when the memory consumption bar turns red (which indicates the overall memory consumption exceeds some threshold predefined somewhere), the software may hang and clicking the garbage can icon will not receive application response, so I had to kill the process.

This means that it will always prefer to allocate memory if more is available, rather than cleaning up after itself.

Another thing I don't understand is, about this lazy memory management of JAVA (openJDK or Oracle JRE?), if it tends to book more memory from the remaining available memory, why the request for more memory stops at 4000MB, whereas I have 32GB memory in total, and normally there are at least 16GB of memory that are free for use. (The most frequently used applications in my machine are oXygen, VS Code, Chrome Browser, Greenshot, and Teams). Perhaps it's possible to adjust some settings to enable JAVA to request for more memory under that strategy?

Regards,
Galano

[adrian]

Hi,

By default, on Windows, Oxygen limits the Java heap memory to 4000MB (-Xmx4000m). This is sufficient for most users. Java needs a reasonable heap limit (not your entire free system memory), otherwise due to the lazy garbage collection it will allocate all the memory that it is allowed to use as heap and the system itself may run out of memory.

This limit is set in the oxygen26.0.vmoptions file from the installation folder.
Increasing the Amount of Memory that Oxygen XML Editor Uses on Windows and Linux
In short, you can either edit this file and change the -Xmx value to something larger. e.g. -Xmx8g
Alternatively, you can create another file named custom_oxygen.vmoptions and specify there the -Xmx argument. The difference is the custom file is preserved when upgrading Oxygen (default file is overwritten).

I don't recommend using more than half of your system memory for Oxygen, as it takes a significant toll on the OS and other apps.

Regards,
Adrian

[galanohan]

Thanks, Adrian! I'll give it a try with 6000 MB for the maxMem of Oxygen...