diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 880cf6fe4fb..5f7e346974c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -30,7 +30,7 @@ reproducing issues and more. Contributions to the website (https://github.com/eclipse-openj9/openj9-website), to the user documentation (https://github.com/eclipse-openj9/openj9-docs), to the system verification tests (https://github.com/eclipse-openj9/openj9-systemtest), or to Eclipse OMR -(https://github.com/eclipse/omr), which is an integral part of OpenJ9 are all +(https://github.com/eclipse-omr/omr), which is an integral part of OpenJ9 are all also welcome. diff --git a/README.md b/README.md index 5222df708df..abdd0e7a032 100644 --- a/README.md +++ b/README.md @@ -46,7 +46,7 @@ What is Eclipse OpenJ9? Eclipse OpenJ9 is an independent implementation of a Java Virtual Machine. "Independent implementation" means it was built using the Java Virtual Machine specification without using any code from any other Java -Virtual Machine. +Virtual Machine. The OpenJ9 JVM combines with the Java Class libraries from OpenJDK to create a complete JDK tuned for footprint, performance, and reliability that is well suited for cloud deployments. @@ -54,7 +54,7 @@ footprint, performance, and reliability that is well suited for cloud deployment The original source contribution to OpenJ9 came from the IBM "J9" JVM which has been used in production by thousands of Java applications for the last two decades. In September 2017, IBM completed open sourcing the J9 JVM as "Eclipse OpenJ9" at the Eclipse Foundation. Significant parts of J9 are also open source -at the [Eclipse OMR project](https://github.com/eclipse/omr). OpenJ9 has a permissive license (Apache +at the [Eclipse OMR project](https://github.com/eclipse-omr/omr). OpenJ9 has a permissive license (Apache License 2.0 or Eclipse Public License 2.0 with a secondary compatibility license for the OpenJDK project's GPLv2 license) that is designed to allow OpenJDK to be built with the OpenJ9 JVM. Please see our [LICENSE file](https://github.com/eclipse-openj9/openj9/blob/master/LICENSE) for more details. diff --git a/buildenv/jenkins/README.md b/buildenv/jenkins/README.md index 2208db6e822..e90f296fd30 100644 --- a/buildenv/jenkins/README.md +++ b/buildenv/jenkins/README.md @@ -116,11 +116,11 @@ You can request a Pull Request build from the Eclipse OpenJ9 repository - [openj ##### Dependent Changes -- If you have dependent change(s) in either eclipse/omr, eclipse-openj9/openj9-omr, or ibmruntimes/openj9-openjdk-jdk\*, you can build & test with all needed changes +- If you have dependent change(s) in either eclipse-omr/omr, eclipse-openj9/openj9-omr, or ibmruntimes/openj9-openjdk-jdk\*, you can build & test with all needed changes - Request a build by including the PR ref or branch name in your trigger comment - Ex. Dependent change in OMR Pull Request `#123` - `Jenkins test sanity xlinux jdk8 depends eclipse/omr#123` -- Ex. Dependent change in eclipse/omr master branch (useful if a dependent OMR PR is already merged) +- Ex. Dependent change in eclipse-omr/omr master branch (useful if a dependent OMR PR is already merged) - `Jenkins test sanity xlinux jdk8 depends eclipse/omr#master` - Ex. Dependent change in OpenJ9-OMR Pull Request `#456` - `Jenkins test sanity xlinux jdk8 depends eclipse-openj9/openj9-omr#456` @@ -243,7 +243,7 @@ Infrastructure pipelines are available [**here**](https://openj9-jenkins.osuosl. - Mirror-OMR-to-OpenJ9-OMR - [![Build Status](https://openj9-jenkins.osuosl.org/buildStatus/icon?job=Mirror-OMR-to-OpenJ9-OMR)](https://openj9-jenkins.osuosl.org/job/Mirror-OMR-to-OpenJ9-OMR) - Description: - - Mirrors [eclipse/omr/master](https://github.com/eclipse/omr/tree/master) to [eclipse-openj9/openj9-omr/master](https://github.com/eclipse-openj9/openj9-omr/tree/master) + - Mirrors [eclipse-omr/omr/master](https://github.com/eclipse-omr/omr/tree/master) to [eclipse-openj9/openj9-omr/master](https://github.com/eclipse-openj9/openj9-omr/tree/master) - Triggers `Pipeline-OMR-Acceptance` when there is new content - Trigger: - Build periodically, 15 minutes diff --git a/buildenv/jenkins/common/build.groovy b/buildenv/jenkins/common/build.groovy index 208d08b786e..f01d26b12ff 100644 --- a/buildenv/jenkins/common/build.groovy +++ b/buildenv/jenkins/common/build.groovy @@ -254,9 +254,9 @@ def checkout_pullrequest() { if (omr_bool) { dir ('omr') { if (omr_upstream) { - sh "git config remote.origin.url https://github.com/eclipse/omr.git" + sh "git config remote.origin.url https://github.com/eclipse-omr/omr.git" } - checkout_pullrequest(OMR_PR, 'eclipse/omr') + checkout_pullrequest(OMR_PR, 'eclipse-omr/omr') } } } diff --git a/buildenv/jenkins/jobs/infrastructure/omrMirror.groovy b/buildenv/jenkins/jobs/infrastructure/omrMirror.groovy index 9f2883bb933..c3ceefd5975 100644 --- a/buildenv/jenkins/jobs/infrastructure/omrMirror.groovy +++ b/buildenv/jenkins/jobs/infrastructure/omrMirror.groovy @@ -23,7 +23,7 @@ timestamps { timeout(time: 1, unit: 'HOURS') { def HTTP = 'https://' - def SRC_REPO = 'github.com/eclipse/omr.git' + def SRC_REPO = 'github.com/eclipse-omr/omr.git' def TARGET_REPO = 'github.com/eclipse-openj9/openj9-omr.git' def ARCHIVE_FILE = "OMR_COMMIT" diff --git a/buildenv/jenkins/variables/defaults.yml b/buildenv/jenkins/variables/defaults.yml index bdb82b9db50..ccc4ce6ca66 100644 --- a/buildenv/jenkins/variables/defaults.yml +++ b/buildenv/jenkins/variables/defaults.yml @@ -57,7 +57,7 @@ openj9: repoUrl: 'https://github.com/eclipse-openj9/openj9.git' omr: default: - repoUrl: 'https://github.com/eclipse/omr.git' + repoUrl: 'https://github.com/eclipse-omr/omr.git' # Adoptium AQA Testing repository adoptopenjdk: default: diff --git a/doc/GuideForCommitters.md b/doc/GuideForCommitters.md index 2fe6cec93eb..c52e990e906 100644 --- a/doc/GuideForCommitters.md +++ b/doc/GuideForCommitters.md @@ -140,7 +140,7 @@ possible between them. It is strongly recommended that you check that the tips of the `eclipse-openj9/openj9-omr` [`master`](https://github.com/eclipse-openj9/openj9-omr/tree/master), `eclipse-openj9/openj9-omr` [`openj9`](https://github.com/eclipse-openj9/openj9-omr/tree/openj9) - and `eclipse/omr` [`master`](https://github.com/eclipse/omr/tree/master) + and `eclipse-omr/omr` [`master`](https://github.com/eclipse-omr/omr/tree/master) branches are all the same before proceeding. If they are different, be aware that you will be introducing other OMR changes that have not yet passed an OMR Acceptance build. While not strictly diff --git a/doc/README.md b/doc/README.md index c2dbff15269..26603ff0529 100644 --- a/doc/README.md +++ b/doc/README.md @@ -34,6 +34,6 @@ This directory contains the following types of documentation: | `processes` | Process documentation for the OpenJ9 project. | | `release-notes` | OpenJ9 release notes. | -:pencil: Developer documentation about OpenJ9 technology or components is best considered in tandem with the [documentation from Eclipse OMR](https://github.com/eclipse/omr/tree/master/doc), as OpenJ9 is built upon the foundational technologies provided by OMR. +:pencil: Developer documentation about OpenJ9 technology or components is best considered in tandem with the [documentation from Eclipse OMR](https://github.com/eclipse-omr/omr/tree/master/doc), as OpenJ9 is built upon the foundational technologies provided by OMR. :pencil: User documentation for OpenJ9 is published at the [OpenJ9 website](https://www.eclipse.org/openj9/docs/) diff --git a/doc/build-instructions/cmake.md b/doc/build-instructions/cmake.md index b99c4ecdd3e..95e382ccd9d 100644 --- a/doc/build-instructions/cmake.md +++ b/doc/build-instructions/cmake.md @@ -37,7 +37,7 @@ can be followed with the following modifications: - removing the `--with-free-marker-jar=` argument - adding `--with-cmake` -:pencil: For more CMake info see [OMR CMake documentation](https://github.com/eclipse/omr/blob/master/doc/BuildingWithCMake.md) +:pencil: For more CMake info see [OMR CMake documentation](https://github.com/eclipse-omr/omr/blob/master/doc/BuildingWithCMake.md) ## FAQ diff --git a/doc/compiler/README.md b/doc/compiler/README.md index ba1ce838a15..7f40704dae6 100644 --- a/doc/compiler/README.md +++ b/doc/compiler/README.md @@ -84,15 +84,15 @@ In the end code generators perform binary encoding to write the appropriate bits * Overview of IL Generator (OMR) * Introduction on Nodes, Trees, Treetops, Blocks, CFGs, and Structures (OMR) - * [Testarossa's Intermediate Language (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/IntroToTrees.md) - * [Symbols, Symbol References, and Aliasing in the OMR compiler (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/SymbolsSymrefsAliasing.md) + * [Testarossa's Intermediate Language (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/IntroToTrees.md) + * [Symbols, Symbol References, and Aliasing in the OMR compiler (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/SymbolsSymrefsAliasing.md) * Reference of IL OpCodes - * [IL OpCodes (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/ILOpcodes.md) - * [Global Register Dependency (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/GlRegDeps.md) - * [Node Transmutation (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/Node.md) - * [Things to Consider When Adding a New IL Opcode (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/ExtendingTrees.md) + * [IL OpCodes (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/ILOpcodes.md) + * [Global Register Dependency (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/GlRegDeps.md) + * [Node Transmutation (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/Node.md) + * [Things to Consider When Adding a New IL Opcode (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/ExtendingTrees.md) * [IL FAQs (OpenJ9)](il/IL_FAQ.md) - * [Tril (OMR)](https://github.com/eclipse/omr/tree/master/doc/compiler/tril) + * [Tril (OMR)](https://github.com/eclipse-omr/omr/tree/master/doc/compiler/tril) *
3. Optimizer @@ -105,22 +105,22 @@ In the end code generators perform binary encoding to write the appropriate bits * [Global Optimizations](optimizer/GlobalOptimizationsSummary.md) * Escape Analysis * [Escape Analysis Optimization in OpenJ9 (YouTube)](https://youtu.be/694S8Tblfcg) - * [Data-Flow Engine (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/DataFlowEngine.md) + * [Data-Flow Engine (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/DataFlowEngine.md) * [Control Flow Optimizations](optimizer/ControlFlowOptimizationsSummary.md) * [Exception Directed Optimization (EDO)](optimizer/EdoOptimization.md) * Inlining - * [Overview of Inlining (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/Inliner.md) - * [BenefitInliner (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/BenefitInliner.md) + * [Overview of Inlining (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/Inliner.md) + * [BenefitInliner (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/BenefitInliner.md) * [Inline Fast Path Locations (OpenJ9)](optimizer/inlineFastPathLocations.md) * [Loop Optimizations](optimizer/LoopOptimizationSummary.md) - * [Introduction on Loop Optimizations (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md) + * [Introduction on Loop Optimizations (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md) * Value Propagation - * [Value Propagation (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) + * [Value Propagation (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) * [Overview of Value Propagation Compiler Optimization (YouTube)](https://youtu.be/694S8Tblfcg) * Hot Code Replacement (HCR) * [Next Gen HCR (OpenJ9)](hcr/OSR.md) * On Stack Replacement (OSR) - * [Introduction to OSR (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/osr/OSR.md) + * [Introduction to OSR (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/osr/OSR.md) * [OSR-based Optimizations (OpenJ9)](hcr/OSR.md) * [Improved JVM Debug Mode Based on OSR (OpenJ9)](https://blog.openj9.org/2019/04/30/introduction-to-full-speed-debug-base-on-osr/) * [Method Handles (OpenJ9)](methodHandles/MethodHandles.md) @@ -134,7 +134,7 @@ In the end code generators perform binary encoding to write the appropriate bits * Tree Evaluator * Register Assignment * X86 - * [X86 Binary Encoding Scheme (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/x/OpCodeEncoding.md) + * [X86 Binary Encoding Scheme (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/x/OpCodeEncoding.md) * PowerPC * s390 * ARM @@ -159,14 +159,14 @@ In the end code generators perform binary encoding to write the appropriate bits *
7. Runtime * Overview of Runtime - * [Code Metadata and Code Metadata Manager (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/runtime/CodeMetaData.md) + * [Code Metadata and Code Metadata Manager (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/runtime/CodeMetaData.md) * [Code Cache Reclamation (OpenJ9)](runtime/CodeCacheReclamation.md) * [Metadata Reclamation (OpenJ9)](runtime/MetadataReclamation.md) * [JIT Hooks (OpenJ9)](runtime/JITHooks.md) * [Recompilation (OpenJ9)](runtime/Recompilation.md) * [Exception Handling (OpenJ9)](runtime/ExceptionHandling.md) * [Runtime Assumption (OpenJ9)](runtime/RuntimeAssumption.md) - * [ELF Generator (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/runtime/ELFGenerator.md#elfgenerator) + * [ELF Generator (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/runtime/ELFGenerator.md#elfgenerator) * [Dynamic Loop Transfer (DLT) (OpenJ9)](https://github.com/eclipse-openj9/openj9/issues/12505) * Stack Walker * [J9JITExceptionTable (OpenJ9)](runtime/J9JITExceptionTable.md) @@ -174,7 +174,7 @@ In the end code generators perform binary encoding to write the appropriate bits *
8. Memory - * [OMR Compiler Memory Manager (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/memory/MemoryManager.md) + * [OMR Compiler Memory Manager (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/memory/MemoryManager.md) * [OpenJ9 Compiler Memory Manager (OpenJ9)](memory/MemoryManager.md) * [Allocating Memory in the Compiler (OpenJ9)](https://blog.openj9.org/2018/06/28/allocating-memory-in-the-compiler/)
@@ -185,24 +185,24 @@ In the end code generators perform binary encoding to write the appropriate bits *
11. Concepts * Extensible Classes - * [Extensible Classes (OMR)](https://github.com/eclipse/omr/tree/master/doc/compiler/extensible_classes) + * [Extensible Classes (OMR)](https://github.com/eclipse-omr/omr/tree/master/doc/compiler/extensible_classes) * [Extensible Classes (YouTube)](https://youtu.be/MtsOdx_1hug) - * [Mainline and Out of Line Code (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/il/MainlineAndOutOfLineCode.md) - * [Regular Expression (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/regular_expression/Regular_Expression.md) + * [Mainline and Out of Line Code (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/MainlineAndOutOfLineCode.md) + * [Regular Expression (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/regular_expression/Regular_Expression.md) * [JIT Write Barriers (OpenJ9)](concepts/JitWriteBarriers.md)
*
12. Debug - * [Problem Determination Guide (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/ProblemDetermination.md) - * [Introduction on Reading JIT Compilation Logs (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/IntroReadLogFile.md) + * [Problem Determination Guide (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/ProblemDetermination.md) + * [Introduction on Reading JIT Compilation Logs (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/IntroReadLogFile.md) * [Part 1: Diagnosing Compilation Problems Using the JIT Verbose Log (YouTube)](https://youtu.be/xG9d4VVRltc) * [Part 2: Diagnosing Compilation Problems Using the JIT Verbose Log (YouTube)](https://youtu.be/S4DSOuIcUo4) * [Command-line Options](https://www.eclipse.org/openj9/docs/cmdline_specifying/) - * [Compiler Options (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/CompilerOptions.md) + * [Compiler Options (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/CompilerOptions.md) * [Lightning Talks - Verbose JIT Logs (YouTube)](https://youtu.be/-bQzHMisg_Y) * [Lightning Talks - JIT Compiler Logs (YouTube)](https://youtu.be/cwCaXQD9PgQ) - * [Debug Counters (OMR)](https://github.com/eclipse/omr/blob/master/doc/compiler/debug/DebugCounters.md) + * [Debug Counters (OMR)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/debug/DebugCounters.md) * JitDump * [Debugging with JitDump (YouTube)](https://youtu.be/hfl6511x8LA) * [JIT Dump (OpenJ9)](https://github.com/eclipse-openj9/openj9/issues/12521) diff --git a/doc/compiler/memory/MemoryManager.md b/doc/compiler/memory/MemoryManager.md index 0af6a6e5200..3292ed844ee 100644 --- a/doc/compiler/memory/MemoryManager.md +++ b/doc/compiler/memory/MemoryManager.md @@ -23,23 +23,23 @@ SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-ex # OpenJ9 Compiler Memory Manager The JIT Compiler in OpenJ9 extends the OMR Compiler. Therefore, it -also extendes the OMR Compiler's Memory Manager, consequently -managing its own memory for the same reasons as the OMR Compiler. -However, in order to ensure that all memory in the JVM is accounted +also extendes the OMR Compiler's Memory Manager, consequently +managing its own memory for the same reasons as the OMR Compiler. +However, in order to ensure that all memory in the JVM is accounted for, as well as to minimize the likelihood of memory leaks, -the OpenJ9 Compiler Memory Manager uses JVM APIs instead +the OpenJ9 Compiler Memory Manager uses JVM APIs instead of OS APIs directly. -Some parts of the memory manager override the OMR implementations, while -others either extend or directly use them. For information on any terms -not documented here, refer to the documentation found in -[eclipse/omr](https://github.com/eclipse/omr/blob/master/doc/compiler/memory/MemoryManager.md). +Some parts of the memory manager override the OMR implementations, while +others either extend or directly use them. For information on any terms +not documented here, refer to the documentation found in +[eclipse-omr/omr](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/memory/MemoryManager.md). ## Compiler Memory Manager Hierarchy ### Low Level Allocators -Low Level Allocators cannot be used by STL containers. They are -generally used by High Level Allocators as the underlying +Low Level Allocators cannot be used by STL containers. They are +generally used by High Level Allocators as the underlying provider of memory. ``` @@ -88,17 +88,17 @@ provider of memory. ``` #### J9::SystemSegmentProvider -`J9::SystemSegmentProvider` implements `TR::SegmentAllocator`. -It uses `J9::J9SegmentProvider` (see below) in order to allocate -`TR::MemorySegment`s and uses `TR::RawAllocator` for all its +`J9::SystemSegmentProvider` implements `TR::SegmentAllocator`. +It uses `J9::J9SegmentProvider` (see below) in order to allocate +`TR::MemorySegment`s and uses `TR::RawAllocator` for all its internal memory management requirements. As part of its initialization, it -preallocates a segment of memory. This is the default Low +preallocates a segment of memory. This is the default Low Level Allocator used by the Compiler. However, the compiler will -use `OMR::DebugSegmentProvider` instead of `J9::SystemSegmentProvider` +use `OMR::DebugSegmentProvider` instead of `J9::SystemSegmentProvider` when the `TR_EnableScratchMemoryDebugging` option is enabled. #### J9::DebugSegmentProvider -`J9::DebugSegmentProvider` implements `TR::SegmentProvider`. +`J9::DebugSegmentProvider` implements `TR::SegmentProvider`. This object exists specifically for the Debugger Extensions. It uses `dbgMalloc`/`dbgFree` to allocate and free memory. @@ -115,7 +115,7 @@ Library provides APIs to allocate/deallocate segments of memory. These segments show up in the `Internal Memory` section of a javacore. They allow the Compiler to minimize the number of times it needs to request memory from the Port Library (an expensive operation for the allocation -patterns exhibited by the Compiler). Therefore, in some sense, +patterns exhibited by the Compiler). Therefore, in some sense, `J9::J9SegmentProvider` is the truest allocator of segments as defined by the Port Library. It should only be used as the backing provider of other Allocators. @@ -134,24 +134,24 @@ deallocation between compilations. ### High level Allocators High Level Allocators can be used by STL containers by wrapping them -in a `TR::typed_allocator` (see below). They generally use a Low +in a `TR::typed_allocator` (see below). They generally use a Low Level Allocator as their underlying provider of memory. #### TR::PersistentAllocator -`TR::PersistentAllocator` is used to allocate memory that persists -for the lifetime of the JVM. This class overrides `OMR::PersistentAllocator`. -It uses `J9::SegmentAllocator` to allocate memory and `TR::RawAllocator` -for all its internal memory management requirements. It receives these -allocators via the `TR::PersistentAllocatorKit`. All allocations/deallocations -are thread safe. Therefore, there is extra overhead due to the need to -acquire a lock before each allocation/dellocation. It also contains an automatic -conversion (which wraps it in a `TR::typed_allocator`) for ease of use with +`TR::PersistentAllocator` is used to allocate memory that persists +for the lifetime of the JVM. This class overrides `OMR::PersistentAllocator`. +It uses `J9::SegmentAllocator` to allocate memory and `TR::RawAllocator` +for all its internal memory management requirements. It receives these +allocators via the `TR::PersistentAllocatorKit`. All allocations/deallocations +are thread safe. Therefore, there is extra overhead due to the need to +acquire a lock before each allocation/dellocation. It also contains an automatic +conversion (which wraps it in a `TR::typed_allocator`) for ease of use with STL containers. #### TR::RawAllocator -`TR::RawAllocator` uses `j9mem_allocate_memory`/`j9mem_free_memory` to allocate -and free memory. This class overrides `TR::RawAllocator` defined in OMR. It also -contains an automatic conversion (which wraps it in a +`TR::RawAllocator` uses `j9mem_allocate_memory`/`j9mem_free_memory` to allocate +and free memory. This class overrides `TR::RawAllocator` defined in OMR. It also +contains an automatic conversion (which wraps it in a `TR::typed_allocator`) for ease of use with STL containers. @@ -164,22 +164,22 @@ The Compiler deals with two categories of allocations: ### Allocations only useful during a compilation Before a Compilation Thread begins going through the list of methods to be compiled, it initializes a `J9::SegmentCache` local object. As stated -above, this will preallocate a segment. Then, it goes through the list. -At the start of a compilation, it initializes a `J9::SystemSegmentProvider`, -passing in the `J9::SegmentCache` as the backing provider (technically it is +above, this will preallocate a segment. Then, it goes through the list. +At the start of a compilation, it initializes a `J9::SystemSegmentProvider`, +passing in the `J9::SegmentCache` as the backing provider (technically it is passed a reference to a `J9::J9SegmentProvider`, the reason for which is described below). As stated above, `J9::SystemSegmentProvider` will allocate a segment as part of its initialization. However, the size of the segment it allocates is the same as the size of the segment preallocated by -`J9::SegmentCache`. Therefore, this operation becomes very inexpensive. If +`J9::SegmentCache`. Therefore, this operation becomes very inexpensive. If `TR_EnableScratchMemoryDebugging` is enabled then -`OMR::DebugSegmentProvider` is used instead. The rest of the process is similar -to that of OMR; it initializes a local `TR::Region` object, and a local -`TR_Memory` object which uses the `TR::Region` for general allocations -(and sub Regions), as well as for the first `TR::StackMemoryRegion`. +`OMR::DebugSegmentProvider` is used instead. The rest of the process is similar +to that of OMR; it initializes a local `TR::Region` object, and a local +`TR_Memory` object which uses the `TR::Region` for general allocations +(and sub Regions), as well as for the first `TR::StackMemoryRegion`. -At the end of the compilation, the `TR::Region` and `J9::SystemSegmentProvider` -(or `OMR::DebugSegmentProvider`) go out of scope, invoking their +At the end of the compilation, the `TR::Region` and `J9::SystemSegmentProvider` +(or `OMR::DebugSegmentProvider`) go out of scope, invoking their destructors and freeing all the memory. However, when `J9::SystemSegmentProvider` releases its memory via `J9::SegmentCache`, the latter will free all memory **EXCEPT** the initial segment it preallocated. @@ -192,20 +192,20 @@ memory. The reason why `J9::SystemSegmentProvider` is passed in a reference to `J9::J9SegmentProvider` and not `J9::SegmentCache` is because the code that -instantiates `J9::SystemSegmentProvider` is common for both compilations on -Compilation Threads AND compilations on Application Threads. When a compilation +instantiates `J9::SystemSegmentProvider` is common for both compilations on +Compilation Threads AND compilations on Application Threads. When a compilation occurs on an Application Thread, `J9::SegmentAllocator` is instantiated instead. -There are a lot of places (thanks to `TR_ALLOC` and related macros) -where memory is explicity allocated. However, `TR::Region` +There are a lot of places (thanks to `TR_ALLOC` and related macros) +where memory is explicity allocated. However, `TR::Region` should be the allocator used for all new code as much as possible. ### Allocations that persist for the lifetime of the JVM -The Compiler initializes a `TR::PeristentAllocator` object when -it is first initialized (close to bootstrap time). For the most -part it allocates persistent memory either directly using the global -`jitPersistentAlloc`/`jitPersistentFree` or via the object methods -added through `TR_ALLOC` (and related macros). `TR::PersistentAllocator` +The Compiler initializes a `TR::PeristentAllocator` object when +it is first initialized (close to bootstrap time). For the most +part it allocates persistent memory either directly using the global +`jitPersistentAlloc`/`jitPersistentFree` or via the object methods +added through `TR_ALLOC` (and related macros). `TR::PersistentAllocator` should be the allocator used for all new code as much as possible. @@ -221,23 +221,23 @@ copy-constructable. The objects die in LIFO order when the Region is destroyed.: to create a `TR::Region` that used `TR::PersistentAllocator` as its backing provider, they would simply need to extend `TR::SegmentProvider`, perhaps calling it `TR::PersistentSegmentProvider`, and have it use -`TR::PersistentAllocator`. The `TR::Region` would then be provided this +`TR::PersistentAllocator`. The `TR::Region` would then be provided this `TR::PersistentSegmentProvider` object. The mechanism for limiting the memory usage during compilation can be summarized as: -Default size of system segments allocatd by `J9::SystemSegmentProvider` is 16 MB. +Default size of system segments allocatd by `J9::SystemSegmentProvider` is 16 MB. These system segments are then carved into smaller segments based on the size requested -which is rounded up to 64 KB. The cumulative memory usage of these system segments is limited +which is rounded up to 64 KB. The cumulative memory usage of these system segments is limited by the value of the option `scratchSpaceLimit`. When the scratch space limit is not a multiple of system segment size, it is possible that the total memory allocated using system segments would go beyond the scratch space limit. However, the logic in `J9::SystemSegmentProvider::request` would ensures that the compiler does not touch memory beyond the scratch space limit. -So the physical memory usage due to scratch space stays with the limit specified. +So the physical memory usage due to scratch space stays with the limit specified. If a request is made that would cause physical memory usage to go beyond the limit, then `J9::SystemSegmentProvider::request` would throw `std::bad_alloc`. When allocating a new system segment `J9::SegmentAllocator::allocate` also checks that the system has enough free physical memory. This is done by verifying that the free physical memory is more -than the system segment size (=16 MB) plus an additional buffer, which is governed by the +than the system segment size (=16 MB) plus an additional buffer, which is governed by the option `safeReservePhysicalMemoryValue`. If this condition fails, then the compilation thread is suspended. diff --git a/doc/compiler/optimizer/ControlFlowOptimizationsSummary.md b/doc/compiler/optimizer/ControlFlowOptimizationsSummary.md index c78e6ca2006..cdbb91dc6f2 100644 --- a/doc/compiler/optimizer/ControlFlowOptimizationsSummary.md +++ b/doc/compiler/optimizer/ControlFlowOptimizationsSummary.md @@ -73,7 +73,7 @@ can be proven that the throw definitely reaches the catch block only and the thrown object is never used in code reachable from the catch block). See [this document](EdoOptimization.md) for an explanation of the mechanics involved. -Note that [Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) +Note that [Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) (which propagates type information) is required to prove that the type of the exception being thrown will be caught by the catch block. Another important pre-requisite for doing EDO successfully is diff --git a/doc/compiler/optimizer/EdoOptimization.md b/doc/compiler/optimizer/EdoOptimization.md index 6a965601fdd..4b37c78377d 100644 --- a/doc/compiler/optimizer/EdoOptimization.md +++ b/doc/compiler/optimizer/EdoOptimization.md @@ -24,7 +24,7 @@ SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-ex [Exception-Directed Optimization (EDO)](ControlFlowOptimizationsSummary.md#exception-directed-optimization-edo) enables more aggressive inlining of methods that throw and catch exceptions to facilitate the transformation of a throw operation into a goto by -[Value Propagation (VP)](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md). +[Value Propagation (VP)](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md). Typically, profiling is used to determine which throw-catch pairs happen often enough to warrant extra inlining. In OpenJ9, the EDO mechanism starts by adding a snippet that decrements the diff --git a/doc/compiler/optimizer/GlobalOptimizationsSummary.md b/doc/compiler/optimizer/GlobalOptimizationsSummary.md index 2e7c960669d..31b11add784 100644 --- a/doc/compiler/optimizer/GlobalOptimizationsSummary.md +++ b/doc/compiler/optimizer/GlobalOptimizationsSummary.md @@ -22,7 +22,7 @@ SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-ex # Global Optimizations -## Global [Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) +## Global [Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) Global Value Propagation (GVP) performs propagation of types, constants, ranges, nullness etc. for value numbers. It requires global value numbering to have been done. GVP performs de-virtualization (followed by inlining in some cases), check removal, branch @@ -133,7 +133,7 @@ tries to find explicit definitions of fields (e.g. in constructors) that occur b any use of the field. In these cases the zero initialization of fields (required according to Java spec) can be skipped. -Note that for reference fields, the presence of a [Garbage Collection (GC) point](https://github.com/eclipse/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) +Note that for reference fields, the presence of a [Garbage Collection (GC) point](https://github.com/eclipse-omr/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) before any user-specified definition means that the field must be zero initialized. The reason why a reference field must be zero initialized before the object is visible to the GC is to prevent the GC from potentially chasing an uninitialized non-zero value @@ -166,7 +166,7 @@ added on ‘cold’ paths to avoid some `monenters/monexits` on ‘hot’ paths. ## Global Register Allocator (GRA) GRA is a solution for achieving the effect of global register assignment, even though the underlying code generators have local register allocators. The basic idea -is that [global register dependencies](https://github.com/eclipse/omr/blob/master/doc/compiler/il/GlRegDeps.md) +is that [global register dependencies](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/GlRegDeps.md) are introduced in the IL trees; these dependencies (when evaluated by the code generators) ensure that a certain value is in a certain register on all control flow paths into a basic block. Stores/loads from memory are @@ -185,7 +185,7 @@ graph-coloring allocator. ## Live Variables for GC Live Variables for GC attempts to minimize the number of reference locals that need to be zero initialized upon method entry. The basic idea is to perform liveness analysis and find -out if any reference locals are live at any [GC point](https://github.com/eclipse/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) +out if any reference locals are live at any [GC point](https://github.com/eclipse-omr/omr/blob/81b79405da6c7c960e611a8b2b12fd5861543330/compiler/il/OMRNode.cpp#L2298) that is not dominated by (user defined) stores on all control flow paths. If a reference local is uninitialized at a GC point, explicit zero initialization must be inserted at the method entry. Note that this situation is fairly rare. Another function of this analysis is to minimize the diff --git a/doc/compiler/optimizer/LocalOptimizationsSummary.md b/doc/compiler/optimizer/LocalOptimizationsSummary.md index 39000f80754..e2105c21f5f 100644 --- a/doc/compiler/optimizer/LocalOptimizationsSummary.md +++ b/doc/compiler/optimizer/LocalOptimizationsSummary.md @@ -38,7 +38,7 @@ evaluated and the resulting register is used at each use of the stored value). Commoning is done on syntactic equivalence. ## Local Value Propagation -Local [Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) +Local [Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md) performs constant, type and relational propagation within a block. It propagates constants and types based on assignments and performs removal of subsumed checks and compares. It also performs devirtualization diff --git a/doc/compiler/optimizer/LoopOptimizationSummary.md b/doc/compiler/optimizer/LoopOptimizationSummary.md index 9eec26701cf..b537b1f7fa8 100644 --- a/doc/compiler/optimizer/LoopOptimizationSummary.md +++ b/doc/compiler/optimizer/LoopOptimizationSummary.md @@ -20,7 +20,7 @@ OpenJDK Assembly Exception [2]. SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-exception-2.0 OR GPL-2.0-only WITH OpenJDK-assembly-exception-1.0 --> -# [Loop Optimizations](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md) +# [Loop Optimizations](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md) ## Loop Canonicalization Loop Canonicalization transforms `while` loops to if-guarded `do-while` loops @@ -44,7 +44,7 @@ also eliminates bound checks where the range of values of the index inside the loop is discovered (if it is a compile time constant) and checks are inserted outside the loop so that no bound checks fail inside the loop. -This analysis uses induction variable information found by [Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md). +This analysis uses induction variable information found by [Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md). Another versioning test that is emitted ensures the loop will not run for a very long period of time (in which case the async check inside the loop can be removed). This special versioning test depends on the number of trees @@ -61,7 +61,7 @@ tests done after each iteration (loop) body. Async checks (yield points) are eliminated from u-1 (u is the unroll factor) unrolled bodies and only one remains. Unroll factors and code growth thresholds are arrived at based on profiling information when available. -This analysis uses induction variable information found by [Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md). +This analysis uses induction variable information found by [Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md). ## Loop Invariant Code Motion Done as part of [Partial Redundancy Elimination (PRE)](optimizer/GlobalOptimizationsSummary.md) @@ -111,7 +111,7 @@ The algorithm for minimizing the async checks in a given loop attempts to achieve its goal by adopting two distinct methods: - Check if the loop is known to be short running (either based on induction -variable information obtained from [Value Propagation](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md)) +variable information obtained from [Value Propagation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/ValuePropagation.md)) or if the special versioning test for short running loops (mentioned earlier) is found. In either case, since the loop is probably not long running, it does not require an async check at all. diff --git a/doc/compiler/optimizer/OptimizerDesignFeatures.md b/doc/compiler/optimizer/OptimizerDesignFeatures.md index 6fb0ea61935..de429114d5c 100644 --- a/doc/compiler/optimizer/OptimizerDesignFeatures.md +++ b/doc/compiler/optimizer/OptimizerDesignFeatures.md @@ -100,7 +100,7 @@ and the mid-invocation transition from compiled code to interpreter is called [O They are valuable tools that can be essential when building JIT compilers for highly dynamic languages. Another aspect of performance is application responsiveness, which is the reason why initial compilations in -the compiler are typically done at [lower optimization levels](https://github.com/eclipse/omr/blob/cf8ddbd1adcd87e388cad6be1fd0e0c085285a29/compiler/compile/CompilationTypes.hpp#L45) +the compiler are typically done at [lower optimization levels](https://github.com/eclipse-omr/omr/blob/cf8ddbd1adcd87e388cad6be1fd0e0c085285a29/compiler/compile/CompilationTypes.hpp#L45) (that are cheaper to do from a compile-time perspective) whereas recompilations are done at higher optimization levels on a more selective basis to avoid paying a high compile-time penalty for every compiled method. @@ -112,9 +112,9 @@ be several times slower than compiled code even at lowest optimization level). The compiler has several optimizations that become more selective depending on the execution frequency of the code it is optimizing. For example, since -[loop versioning](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md#2-loop-versioner) -and [specialization](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md#4-loop-specializer), -loop unrolling, [inlining](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/Inliner.md), +[loop versioning](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md#2-loop-versioner) +and [specialization](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md#4-loop-specializer), +loop unrolling, [inlining](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/Inliner.md), and tail splitting are optimizations that cause code growth, care must be taken that the code growth and subsequent compile-time increase in optimizations that run later are worth the runtime benefit. @@ -180,7 +180,7 @@ There are also other forms of speculation done by the compiler, especially aroun Higher level semantic knowledge that exceptions are rarely expected to be raised in most well-behaved programs is used to drive optimization. -The [loop versioner](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md#2-loop-versioner) +The [loop versioner](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/IntroLoopOptimizations.md#2-loop-versioner) clones a loop and eliminates all the exception checks that are loop invariant or on induction variables from inside the good version of the loop based on a series of tests it emits before the loop is entered by checking the equivalent conditions (more efficient since the checking is done once outside the loop @@ -251,7 +251,7 @@ particularly convenient for doing local optimizations. The DAG representation is less expensive from a memory footprint viewpoint since a single value within an extended basic block is represented by a single node regardless of how many consumers (parent nodes in the -OpenJ9 JIT [IL representation](https://github.com/eclipse/omr/blob/master/doc/compiler/il/IntroToTrees.md)) +OpenJ9 JIT [IL representation](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/il/IntroToTrees.md)) of the value there are in that extended basic block. It also makes the concept of "value equality" trivial for most local analyses, since this basically just @@ -269,7 +269,7 @@ exception catch block (if there exists one in the method) and exception edges re Crucially this is done without ending the basic block every time an exception check is encountered, and the "special" nature of exception checks and edges is known to the compiler's generic -[dataflow analysis](https://github.com/eclipse/omr/blob/master/doc/compiler/optimizer/DataFlowEngine.md) framework, +[dataflow analysis](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/optimizer/DataFlowEngine.md) framework, so that it does the right operations every time those special idioms are encountered. This decreases the complexity of the CFG in general and makes the control flow look largely like it would have diff --git a/doc/compiler/optimizer/inlineFastPathLocations.md b/doc/compiler/optimizer/inlineFastPathLocations.md index c8fcbd50658..8a080be4de2 100644 --- a/doc/compiler/optimizer/inlineFastPathLocations.md +++ b/doc/compiler/optimizer/inlineFastPathLocations.md @@ -26,7 +26,7 @@ SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-ex When there is a call to a method, the call can be executed in a cheaper way rather than making a call out to the target method. The inlined fast path converts a recognized call into a cheaper sequence of IL trees. One example is a call to a -`java.lang.Math.abs()`. It can be converted into an `iabs` (absolute value of integer) [opcode](https://github.com/eclipse/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/il/OMROpcodes.enum#L1911). The call to `java.lang.Math.abs()` can be eliminated because there is a better +`java.lang.Math.abs()`. It can be converted into an `iabs` (absolute value of integer) [opcode](https://github.com/eclipse-omr/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/il/OMROpcodes.enum#L1911). The call to `java.lang.Math.abs()` can be eliminated because there is a better representation of the execution in IL, which is cheaper. This is a basic pattern of taking a call, recognizing them in a certain way, and optimizing it, sometimes using opcode, sometimes using a sequence of IL trees etc. @@ -34,8 +34,8 @@ in a certain way, and optimizing it, sometimes using opcode, sometimes using a s There are multiple locations in our code where we do inline fast path optimizations: 1. [IL Generator](https://github.com/eclipse-openj9/openj9/tree/master/runtime/compiler/ilgen) -2. [Inliner](https://github.com/eclipse/omr/blob/master/compiler/optimizer/Inliner.cpp) -3. [RecognizedCallTransformer](https://github.com/eclipse/omr/blob/master/compiler/optimizer/OMRRecognizedCallTransformer.cpp) +2. [Inliner](https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/Inliner.cpp) +3. [RecognizedCallTransformer](https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/OMRRecognizedCallTransformer.cpp) 4. [UnsafeFastPath](https://github.com/eclipse-openj9/openj9/blob/master/runtime/compiler/optimizer/UnsafeFastPath.cpp) ## Inlining Fast Path Optimization In ILGen @@ -45,7 +45,7 @@ in Java bytecodes. It must track how many things are on the stack. It is not a v transformations. It is easier to do the transformation on well-formed trees rather than during the trees are being generated. ILGen should be kept as simple as possible. The task of optimizations should not be mixed with the task of generating IL. -After IL is generated, [ilgenStrategyOpts](https://github.com/eclipse/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/optimizer/OMROptimizer.cpp#L535-L544) will run before other optimizations see the IL. +After IL is generated, [ilgenStrategyOpts](https://github.com/eclipse-omr/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/optimizer/OMROptimizer.cpp#L535-L544) will run before other optimizations see the IL. `ilgenStrategyOpts` always runs as soon as IL is generated. For example for normal inlining, after ILGen runs to produce the IL for the callee method, `ilgenStrategyOpts` also runs on the generated IL before the method is inlined into the caller. @@ -102,7 +102,7 @@ call in `ConcurrentHashMap` will never see a `NULL` array object. It will be gua Things like this can be determined during the compilation. Therefore, all the checking can be skipped. We could just do the load or store. -`UnsafeFastPath` also [runs as a part of](https://github.com/eclipse/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/optimizer/OMROptimizer.cpp#L543) `ilgenStrategyOpts` before `recognizedCallTransformer`. +`UnsafeFastPath` also [runs as a part of](https://github.com/eclipse-omr/omr/blob/e3a15a993c8aba80582aa1d6f3071e122acbd4c4/compiler/optimizer/OMROptimizer.cpp#L543) `ilgenStrategyOpts` before `recognizedCallTransformer`. It does a relatively simple substitution of certain calls very early without adding control flow before the inliner even runs (so it never sees these calls in the IL trees). diff --git a/doc/compiler/osr/OSR.md b/doc/compiler/osr/OSR.md index 93d2868d3c3..08a1960e448 100644 --- a/doc/compiler/osr/OSR.md +++ b/doc/compiler/osr/OSR.md @@ -1,7 +1,7 @@ # Introduction -This document describes several OpenJ9 optimizations that use the OSR mechanism described in [OMR OSR document](https://github.com/eclipse/omr/blob/master/doc/compiler/osr/OSR.md). These optimizations include: +This document describes several OpenJ9 optimizations that use the OSR mechanism described in [OMR OSR document](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/osr/OSR.md). These optimizations include: * Full Speed Debug (FSD) * Next Generation Hot Code Replacement (nextGenHCR) @@ -43,7 +43,7 @@ The guard would be patched if the method it protected was redefined - this stops The control-flow diamond this would create is the reason for the throughput performance overhead mentioned previously - the cold call on the taken side of the guard causes most analyses to become very conservative due to the arbitrary nature of the code the call may run. -Unlike traditional HCR, nextGenHCR implements HCR using OSR. OSR is described in detail in [OMR OSR document](https://github.com/eclipse/omr/blob/master/doc/compiler/osr/OSR.md). NextGenHCR will transition back to the VM when +Unlike traditional HCR, nextGenHCR implements HCR using OSR. OSR is described in detail in [OMR OSR document](https://github.com/eclipse-omr/omr/blob/master/doc/compiler/osr/OSR.md). NextGenHCR will transition back to the VM when a redefinition occurs, rather than simply calling the redefined method. This eliminates the control-flow diamond and allows more optimizations to happen on the inlined path. @@ -283,4 +283,4 @@ This optimization uses the same infrastructure as nextGenHCR except that the fea # OSR On Guard Failure -If OSR on guard failure is enabled (with ```-Xjit:enableOSROnGuardFailure```) when a guard fails, instead of taking the cold path we trigger an OSR. This is implemented as a voluntary pre-execution OSR. \ No newline at end of file +If OSR on guard failure is enabled (with ```-Xjit:enableOSROnGuardFailure```) when a guard fails, instead of taking the cold path we trigger an OSR. This is implemented as a voluntary pre-execution OSR. diff --git a/doc/diagnostics/CallingConventions.md b/doc/diagnostics/CallingConventions.md index 9b4ab70adaa..42a91fa54b9 100644 --- a/doc/diagnostics/CallingConventions.md +++ b/doc/diagnostics/CallingConventions.md @@ -20,9 +20,9 @@ OpenJDK Assembly Exception [2]. SPDX-License-Identifier: EPL-2.0 OR Apache-2.0 OR GPL-2.0-only WITH Classpath-exception-2.0 OR GPL-2.0-only WITH OpenJDK-assembly-exception-1.0 --> -This document describes the calling conventions for the JIT Private +This document describes the calling conventions for the JIT Private Linkage. The System Linkage info can be found in the -[Eclipse OMR Project](https://github.com/eclipse/omr/blob/master/doc/diagnostics/CallingConventions.md). +[Eclipse OMR Project](https://github.com/eclipse-omr/omr/blob/master/doc/diagnostics/CallingConventions.md). # x86 @@ -69,12 +69,12 @@ Linkage. The System Linkage info can be found in the ## IA32 -The IA32 calling convention in the private linkage pushes all arguments on to the -stack in left-to-right order, i.e. in the case of an indirect call, the receiver -object is furthest away from the top of the Java stack. The callee is responsible -for cleaning up the pushed arguments. The return value is placed in EAX, or -EDX:EAX for a long value. If SSE2 support is not available, the x87 floating-point -stack is used for passing floating-point arguments and returning floating-point +The IA32 calling convention in the private linkage pushes all arguments on to the +stack in left-to-right order, i.e. in the case of an indirect call, the receiver +object is furthest away from the top of the Java stack. The callee is responsible +for cleaning up the pushed arguments. The return value is placed in EAX, or +EDX:EAX for a long value. If SSE2 support is not available, the x87 floating-point +stack is used for passing floating-point arguments and returning floating-point results. Otherwise, XMM registers are used. # POWER diff --git a/doc/diagnostics/VMState.md b/doc/diagnostics/VMState.md index 45c8f4672b4..a6916a0f430 100644 --- a/doc/diagnostics/VMState.md +++ b/doc/diagnostics/VMState.md @@ -30,7 +30,7 @@ which compilation phase the compiler is in. If the VM crashes for any reason, the VM state is reported via standard error and in the javacore dump (in which it is referred to as "VM flags"), and serves as a first-order indicator of the failing component during problem -determination. +determination. [1]: https://github.com/eclipse-openj9/openj9/blob/master/runtime/oti/j9nonbuilder.h @@ -79,7 +79,7 @@ If the entire low-order half of the VM state is 0xFFFF, then the active component is likely to be in the compiler initialization or the IL generator. -[2]: https://github.com/eclipse/omr/blob/master/compiler/optimizer/Optimizations.hpp +[2]: https://github.com/eclipse-omr/omr/blob/master/compiler/optimizer/Optimizations.hpp [3]: https://github.com/eclipse-openj9/openj9/blob/master/runtime/compiler/codegen/J9CodeGenPhaseEnum.hpp ## Finding the VM state examples @@ -101,11 +101,11 @@ R12=0000040001BA7050 R13=0000040000CE9920 R14=000000001028E570 R15=00000000100A9 In a javacore dump search for the `HFLAGS` to find the VM state. ``` -2XHREGISTER ... +2XHREGISTER ... 1XHEXCPMODULE Compiling method: javax/naming/NameImpl.(Ljava/util/Properties;)V -NULL +NULL 1XHFLAGS VM flags:0000000000051AFF -NULL +NULL NULL ------------------------------------------------------------------------ 0SECTION ENVINFO subcomponent dump routine NULL ================================= diff --git a/doc/release-notes/0.22/0.22.md b/doc/release-notes/0.22/0.22.md index 172dc66a1d2..1f071e0cbd3 100644 --- a/doc/release-notes/0.22/0.22.md +++ b/doc/release-notes/0.22/0.22.md @@ -53,9 +53,9 @@ The following table covers notable changes in v0.22.0. Further information about -#9731, -#9993, -#5436, +#9731, +#9993, +#5436, #10305 New -XX:[+|-]PortableSharedCache option added All versions diff --git a/doc/release-notes/0.25/0.25.md b/doc/release-notes/0.25/0.25.md index 458702e4326..5f5875b5647 100644 --- a/doc/release-notes/0.25/0.25.md +++ b/doc/release-notes/0.25/0.25.md @@ -70,7 +70,7 @@ The following table covers notable changes in v0.25.0. Further information about -#5770 +#5770 z/OS® support for the %sysname dump token All versions The %sysname dump token is added on z/OS, which equates to the SYSNAME sysparm. diff --git a/doc/release-notes/0.30/0.30.1.md b/doc/release-notes/0.30/0.30.1.md index 1ce701b35e7..a630b13cfe6 100644 --- a/doc/release-notes/0.30/0.30.1.md +++ b/doc/release-notes/0.30/0.30.1.md @@ -48,7 +48,7 @@ The following table covers notable changes in v0.30.1. Further information about -eclipse/omr#6319 +eclipse-omr/omr#6319 Creation of system (core) dumps on macOS 12 macOS Creation of system (core) dumps on macOS 12 or later is now possible. diff --git a/doc/release-notes/0.33/0.33.md b/doc/release-notes/0.33/0.33.md index ebdce40caaf..b8d388fde31 100644 --- a/doc/release-notes/0.33/0.33.md +++ b/doc/release-notes/0.33/0.33.md @@ -161,7 +161,7 @@ if running on a Skylake or later processor. -#6432 +#6432 If you mount the /proc file system with the hidepid=2 option on Linux systems and the VM does not have root privileges, it cannot access the /proc/1/cgroup file and the container detection fails. All versions (Linux) The VM fails to start when the container detection code cannot access the /proc/1/cgroup file. diff --git a/doc/release-notes/0.35/0.35.md b/doc/release-notes/0.35/0.35.md index e5424927852..d9f6ddb75e5 100644 --- a/doc/release-notes/0.35/0.35.md +++ b/doc/release-notes/0.35/0.35.md @@ -96,7 +96,7 @@ The following table covers notable changes in v0.35.0. Further information about -#6432 +#6432 If you mount the /proc file system with the hidepid=2 option on Linux systems and the VM does not have root privileges, it cannot access the /proc/1/cgroup file and the container detection fails. All versions (Linux) The VM fails to start when the container detection code cannot access the /proc/1/cgroup file. diff --git a/doc/release-notes/0.36/0.36.md b/doc/release-notes/0.36/0.36.md index 46a8cf9f32b..f0480e6e0a2 100644 --- a/doc/release-notes/0.36/0.36.md +++ b/doc/release-notes/0.36/0.36.md @@ -162,7 +162,7 @@ You can also disa -#6432 +#6432 If you mount the /proc file system with the hidepid=2 option on Linux systems and the VM does not have root privileges, it cannot access the /proc/1/cgroup file and the container detection fails. All versions (Linux) The VM fails to start when the container detection code cannot access the /proc/1/cgroup file. diff --git a/doc/release-notes/0.37/0.37.md b/doc/release-notes/0.37/0.37.md index 01919238c0a..ff6727c06c3 100644 --- a/doc/release-notes/0.37/0.37.md +++ b/doc/release-notes/0.37/0.37.md @@ -173,7 +173,7 @@ on x64 platforms, but builds with OpenJDK 17 and later also require more stack s -#6432 +#6432 If you mount the /proc file system with the hidepid=2 option on Linux systems and the VM does not have root privileges, it cannot access the /proc/1/cgroup file and the container detection fails. All versions (Linux) The VM fails to start when the container detection code cannot access the /proc/1/cgroup file. diff --git a/doc/release-notes/0.38/0.38.md b/doc/release-notes/0.38/0.38.md index 1e95e734a0d..4234a53db63 100644 --- a/doc/release-notes/0.38/0.38.md +++ b/doc/release-notes/0.38/0.38.md @@ -123,7 +123,7 @@ on x64 platforms, but builds with OpenJDK 17 and later also require more stack s -#6432 +#6432 If you mount the /proc file system with the hidepid=2 option on Linux systems and the VM does not have root privileges, it cannot access the /proc/1/cgroup file and the container detection fails. All versions (Linux) The VM fails to start when the container detection code cannot access the /proc/1/cgroup file. diff --git a/doc/release-notes/0.39/0.39.md b/doc/release-notes/0.39/0.39.md index fab7c223c04..1747a612008 100644 --- a/doc/release-notes/0.39/0.39.md +++ b/doc/release-notes/0.39/0.39.md @@ -104,7 +104,7 @@ on x64 platforms, but builds with OpenJDK 17 and later also require more stack s -#6432 +#6432 If you mount the /proc file system with the hidepid=2 option on Linux® systems and the VM does not have root privileges, it cannot access the /proc/1/cgroup file and the container detection fails. All versions (Linux) The VM fails to start when the container detection code cannot access the /proc/1/cgroup file. diff --git a/doc/release-notes/0.40/0.40.md b/doc/release-notes/0.40/0.40.md index b34c8c3d119..4af2059f74e 100644 --- a/doc/release-notes/0.40/0.40.md +++ b/doc/release-notes/0.40/0.40.md @@ -62,7 +62,7 @@ The following table covers notable changes in v0.40.0. Further information about -#7021 +#7021 If you mount the /proc file system with the hidepid=2 option on Linux® systems and the VM does not have root privileges, it cannot access the /proc file system, and the container detection fails. But, the VM does not exit as it did in the previous releases. Now, the VM starts with a warning message. All versions (Linux) Although the VM starts after the container detection fails, the VM assumes that it is running outside a container. Therefore, if the VM is running in a container, the VM cannot adapt to the container's limitations and might use an undesirable amount of resources. You can evaluate the impact on performance because of the container detection failure and take steps to resolve the performance issue, if so required. For example, you can remount the /proc file system with the gid and hidepid=2 options to allow some processes to access the /proc file system. diff --git a/doc/release-notes/0.9/0.9.md b/doc/release-notes/0.9/0.9.md index 96a950a72dc..7f9120df74b 100644 --- a/doc/release-notes/0.9/0.9.md +++ b/doc/release-notes/0.9/0.9.md @@ -111,8 +111,8 @@ The following table covers notable changes in v0.9.0. Further information about #1603, #1642, -eclipse/omr#2494, -eclipse/omr#2524 +eclipse-omr/omr#2494, +eclipse-omr/omr#2524 Full support for shutdown signals All Linux variants, AIX diff --git a/jcl/src/openj9.dtfj/share/classes/com/ibm/jvm/j9/dump/indexsupport/NodeGPF.java b/jcl/src/openj9.dtfj/share/classes/com/ibm/jvm/j9/dump/indexsupport/NodeGPF.java index 6b5d56aa94d..eedd4a4a1c0 100644 --- a/jcl/src/openj9.dtfj/share/classes/com/ibm/jvm/j9/dump/indexsupport/NodeGPF.java +++ b/jcl/src/openj9.dtfj/share/classes/com/ibm/jvm/j9/dump/indexsupport/NodeGPF.java @@ -68,7 +68,7 @@ public void stringWasParsed(String string) // These ultimately came from omr/include_core/omrport.h (passed through // runtime/oti/j9port.h). NodeGPF is for processing older core dump // jextract XMLs, so although some of these constants changed with - // https://github.com/eclipse/omr/pull/3921, the following should be fixed + // https://github.com/eclipse-omr/omr/pull/3921, the following should be fixed // in time. private final static int J9PORT_SIG_FLAG_SIGSEGV = 4; private final static int J9PORT_SIG_FLAG_SIGBUS = 8; diff --git a/runtime/CMakeLists.txt b/runtime/CMakeLists.txt index cdd63d3eeed..fabf82efc58 100644 --- a/runtime/CMakeLists.txt +++ b/runtime/CMakeLists.txt @@ -321,7 +321,7 @@ target_link_libraries(j9vm_main_wrapper ### # set up glue library target names -# See https://github.com/eclipse/omr/blob/master/doc/BuildingWithCMake.md +# See https://github.com/eclipse-omr/omr/blob/master/doc/BuildingWithCMake.md set(OMR_GC_GLUE_TARGET "j9vm_gc_glue" CACHE INTERNAL "") set(OMR_GC_GLUE_FULL_TARGET "j9vm_gc_glue_full" CACHE INTERNAL "") set(OMR_RAS_GLUE_TARGET "j9vm_ras_glue" CACHE INTERNAL "") diff --git a/runtime/compiler/z/codegen/J9BCDTreeEvaluator.cpp b/runtime/compiler/z/codegen/J9BCDTreeEvaluator.cpp index 96e9c54900b..aef18277f89 100644 --- a/runtime/compiler/z/codegen/J9BCDTreeEvaluator.cpp +++ b/runtime/compiler/z/codegen/J9BCDTreeEvaluator.cpp @@ -3028,7 +3028,7 @@ J9::Z::TreeEvaluator::pdnegEvaluator(TR::Node * node, TR::CodeGenerator * cg) { // This path used to contain a call to an API which would have returned a garbage result. Rather than 100% of the // time generating an invalid sequence here which is guaranteed to crash if executed, we fail the compilation. - cg->comp()->failCompilation("Existing code relied on an unimplemented API and is thus not safe. See eclipse/omr#5937."); + cg->comp()->failCompilation("Existing code relied on an unimplemented API and is thus not safe. See eclipse-omr/omr#5937."); } if (isSignManipulation) diff --git a/test/functional/JIT_Test/src/jit/test/jitt/misc/SanityCompareAndBranch.java b/test/functional/JIT_Test/src/jit/test/jitt/misc/SanityCompareAndBranch.java index 223e46293de..412a91d063c 100644 --- a/test/functional/JIT_Test/src/jit/test/jitt/misc/SanityCompareAndBranch.java +++ b/test/functional/JIT_Test/src/jit/test/jitt/misc/SanityCompareAndBranch.java @@ -30,11 +30,11 @@ public class SanityCompareAndBranch extends jit.test.jitt.Test { /** * Following method when JIT compiled deterministically (Fix optimization level), contains a tree * that compares two VFT pointers, one of which is stored on temporary java stack slots while other - * from the object. + * from the object. * On 64-Bit platform with Compressed references, this will test the code path to generate instruction * for `if` tree where one child is 8 byte memory load while other child is 4 byte memory load. * - * For more details see eclipse/omr#4763 + * For more details see eclipse-omr/omr#4763 */ private int testAddressCompare(Object obj1, Object obj2) { int retVal = 0; diff --git a/test/functional/JIT_Test/src/jit/test/ra/TestOOLSpill31Bit.java b/test/functional/JIT_Test/src/jit/test/ra/TestOOLSpill31Bit.java index b479075662f..2e22774edea 100644 --- a/test/functional/JIT_Test/src/jit/test/ra/TestOOLSpill31Bit.java +++ b/test/functional/JIT_Test/src/jit/test/ra/TestOOLSpill31Bit.java @@ -45,7 +45,7 @@ public static final BigInteger powerOfTenBI(long i) { * On 31-bit platforms when using 64-bit registers we can encounter problems in this path if the register allocator * fails to properly spill 64-bit values across an OOL code section. * - * @see eclipse/omr#3337 + * @see eclipse-omr/omr#3337 */ @Test public static void testOOLSpill31Bit() {