Avoid linear search if OMRPORT_VMEM_ALLOC_QUICK option is specified #2796
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Updated to avoid linear search only if |
keithc-ca
changed the title
|
fyi an OpenJ9 Pull Request build with this change took about 1.5 hours. Reduced from about 7 hours for running the sanity tests without this change. Details in eclipse-openj9/openj9#2329 |
This was referenced Jul 25, 2018
|
@genie-omr build all |
|
The port library vmem test is failing on linux ppc le gcc build and the linux x64 compressed references build is failing to compile for some really weird reason... |
|
I restarted the Linux x64 compressed references autotools build and it failed to compiled in the exact same way. |
* update findAvailableMemoryBlockNoMalloc to consider more free regions when OMRPORT_VMEM_STRICT_ADDRESS is not specified * if findAvailableMemoryBlockNoMalloc returns NULL, we now interpret that to mean there is no suitable block available and a linear search would just be a waste of time * encountering EOF in findAvailableMemoryBlockNoMalloc is normal (especially for a reverse search) - it isn't (by itself) a sign of data corruption * update documentation for OMRPORT_VMEM_ALLOC_QUICK in omrport.h * add missing calls to free memory in omrmemTest to reduce interference with later tests * tests: initialize local variables in declarations Signed-off-by: Keith W. Campbell <[email protected]>
|
Change updated:
|
|
@genie-omr build all |
This was referenced Jul 31, 2018
Merged
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
On some Linux systems (e.g. s390x) the initial text segment is loaded at virtual address
0x80000000. (I suspect, but don't know how to verify, that this is new behavior on zLinux which lead to eclipse-openj9/openj9#2388.)A 2GB heap (either because the system has 8GB of RAM or the user explicitly requested that size) cannot be allocated below 4GB (to avoid the need for a non-zero shift for compressed references).
The old (documented) behavior of the
OMRPORT_VMEM_ALLOC_QUICKoption is to fall back to a linear search, which in our example will make 512k attempts to allocate blocks at multiples of 4k - all of which will fail. This only serves to delay returning toMM_MemoryManager::createVirtualMemoryForHeapwhere it can retry with larger shifts for compressed references.