Add information about compressed refs and SOA/LOA #683
Conversation
|
Jenkins doc stage |
SueChaplain
force-pushed
the
comp-refs
branch
from
0c2277f to
23ea832
Compare
SueChaplain
changed the title
|
Jenkins doc stage |
SueChaplain
force-pushed
the
comp-refs
branch
2 times, most recently
from
8bc4d1f to
5bfbd3a
Compare
|
Jenkins doc stage |
SueChaplain
force-pushed
the
comp-refs
branch
from
5bfbd3a to
e678b69
Compare
|
@dmitripivkine - can you help out here please. I've overwhelmed Aleks with other stuff. The LOA/SOA content is already reviewed/approved, but the compressed refs content needs checking. Staged at https://eclipse.github.io/openj9-docs-staging/683/allocator/ |
|
Jenkins doc stage |
docs/allocator.md
Outdated
| Compressed references are used by default when the maximum Java heap size is in the range 0 - 57 GB on AIX®, Linux®, and Windows® systems. The upper limit is also 57 GB on z/OS® systems that have APAR OA49416 | ||
| installed (25 GB without APAR OA49416). All GC policies observe these limits except for the [`metronome`](gc.md#metronome-policy) policy, which can only support a heap size of up to 25 GB with compressed references. | ||
|
|
||
| When the VM uses compressed references, classes, threads, and monitors are stored in the lowest 4 GB of address space. However, this area of memory is also used by native libraries, the operating system, and for small Java heaps. If you receive native memory `OutOfMemoryError` exceptions when running with compressed references enabled, these errors might result from the lowest 4 GB of address space becoming full. Try specifying a large heap with the [`-Xmx`](xms.md) option, which puts the Java heap into a higher area of address space or using the [`-Xmcrs`](xmcrs.md) option to reserve space in the lowest 4 GB of address space for compressed references. |
There was a problem hiding this comment.
I believe we can be more specific regarding OOM type: "out of native memory below 4GB bar". If we have description of possible types of OOM the wording should match obviously.
|
|
||
| ### Compressed references |
There was a problem hiding this comment.
Please be aware that this paragraph might require editing in nearest future with introduction of Compressed/Full 64-bit Mixed build (planned for 0.25 release). This single build is going to replace current "Compressed" and "Large Heap" builds. The running mode "Compressed" or "Full 64-bit" will be selected automatically based on provided command line options.
There was a problem hiding this comment.
Noted @dmitripivkine - thanks. I guess we will have a docs issue for this to ensure it isn't missed.
docs/xms.md
Outdated
| @@ -51,6 +49,13 @@ If the scavenger is disabled, `-Xms` ≥ `-Xmo` | |||
| See [Using -X command-line options](x_jvm_commands.md) for more information about the `<size>` parameter. | |||
| See [Default settings for the OpenJ9 VM](openj9_defaults.md) for more about default values. | |||
|
|
|||
| ### Calculating `-Xmx` for large pages | |||
|
|
|||
| For z/OS® and Linux® on IBM Z®, specifying an object heap size that is a multiple of the page size uses another page of memory. For example, if the page size is 2 GB, setting `-Xmx2G` actually uses 4 GB of memory. To avoid using more memory, make the heap size a little smaller than an integral number of pages by subtracting at least 16 bytes from the value that you set with the `-Xmx` option. The following examples are provided: | |||
There was a problem hiding this comment.
I am pretty sure this is obsolete. The 8 bytes tail padding on z platforms has been removed. This entire paragraph is not needed any more.
There was a problem hiding this comment.
FYI Object Heap Tail Padding (allocation slightly more memory than requested) is done by performance improvement reason if -Xaggressive option is provided for all platforms. If size of physical page is smaller than 1GB one extra memory page is allocated. If size of physical page is equal or larger than 1GB no extra memory is allocated.
There was a problem hiding this comment.
I am pretty sure this is obsolete.
Yes you are right, I didn't spot the tagging in the topic we were referencing. Removing this section and the bullet at the top that replaced the original incorrect reference:
If you are allocating the Java heap with large pages, see also -Xlp and
More effective heap usage using compressed references.
|
In general may be make sense to add examples how |
SueChaplain
requested review from
pmhayward
and removed request for
pshipton and
amicic
|
@pmhayward - the changed content here has now been reviewed (SOA/LOA by Aleks, compressed refs by Dmitri). Please can you take a quick look and merge if you are happy. There are further structural changes I hope to put in before 0.24, so would like to proceed with these. Thanks. |
- add to memory allocation topic - link to -Xmx topic for large page guidance Signed-off-by: SueChaplain <[email protected]>
SueChaplain
force-pushed
the
comp-refs
branch
from
e678b69 to
cbc7eaa
Compare
|
Jenkins doc stage |
|
LGTM |
Signed-off-by: SueChaplain [email protected]