Should we obsolete "memorysize" in FlightRecorderOptions?

[Markus Gronlund]

Hi Denghui,

I think _limit_size was used in assertions previously to warn about improper use of an mspace, but as you point out, it is not used now. It is _implicitly_ enforced however for the global mspace because the usage is known (the limit is allocated up front at the start and new memory is never allocated during runtime). So "memorysize" is respected and is used to configure the global mspace, if not actually asserted.

This leads to another aspect of the "memorysize" option; it would be a mistake to interpret this value as a hard limit for the total memory footprint used by JFR. The reasons are many, for example alignments and recalculations for proper ratios. More importantly, there is a section of memory used by JFR that is a function of the number of threads in the system (that’s why you see the _thread_local_mspace and _transient_mspaces being unlimited). A thread must always be able to do a thread local write. There is also auxiliary memory such as storage for string pool, checkpoints and more.

Introduction of the "memorysize" option was an attempt to make it easier to configure of the dominating factor of the JFR memory working set, namely the size of the global buffers and their counts. Previously there was only the more low level options such as "globalbuffersize" and "globalbuffercount" available. But it was / is hard to understand what would constitute a good ratio between them if a user would like to increase the overall memory size.

The intent with "memorysize", is to have a single value be given, say "memorysize=300M" and then the memory sizing factors would be derived from this value. Again, it is not a hard and fast limit (can't be), but an easy means to configure the dominating factor of the global memory system.

Assertions could be reinserted to check for _limit_size to avoid wrong usage of an mspace, as well as to help improve code documentation. I also think the description of the "memorysize" option in the documentation can be improved to better specify the semantics to avoid setting the wrong expectations. There is some control for the user as in the size of the global mspace will end up close to the suggested value (modulo page alignments and ratio calculations), but there also exist other memory that need to be unbounded (at least with the current design). It is a hint more a hard limit.

Thanks
Markus



-----Original Message-----
From: Denghui Dong <denghui.ddh at alibaba-inc.com> 
Sent: den 1 april 2020 11:18
To: hotspot-jfr-dev <hotspot-jfr-dev at openjdk.java.net>
Subject: Should we obsolete "memorysize" in FlightRecorderOptions?

Hi team,

I notice that JfrMemorySpace::_limit_size is never used(maybe I'm wrong), and _limit_size of _global_mspace will use the value of "memorysize"(default 10m) in FlightRecorderOptions.

Should we obsolete it or use it to limit the max size of JfrMemorySpace? 
I'm worried that users think they can use "memorysize" to control the size of memory to be used by JFR, but actually they can't.

is it right?

Thanks,
Denghui Dong