From vromero at openjdk.java.net Tue Apr 12 04:44:28 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 12 Apr 2022 04:44:28 GMT Subject: Integrated: Merge lworld Message-ID: Merge lworld ------------- Commit messages: - Merge branch 'lworld' into universal-tvars_merge_lworld_now - Merge lworld - changing universal lint warning to unchecked warning - Merge lworld - Build failing in universal tvars - bug: no warning shown for parameterized conversions - addressing a NPE in the compiler due to empty warnStack - some test refactorings - type of TypeVar.ref is incorrect and should be fixed - clean up to warnings related code - ... and 17 more: https://git.openjdk.java.net/valhalla/compare/9b9365df...eef8bdfb The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.java.net/valhalla/pull/683/files Stats: 1563 lines in 36 files changed: 1421 ins; 28 del; 114 mod Patch: https://git.openjdk.java.net/valhalla/pull/683.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/683/head:pull/683 PR: https://git.openjdk.java.net/valhalla/pull/683 From vromero at openjdk.java.net Tue Apr 12 04:44:29 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Tue, 12 Apr 2022 04:44:29 GMT Subject: Integrated: Merge lworld In-Reply-To: References: Message-ID: On Tue, 12 Apr 2022 04:34:47 GMT, Vicente Romero wrote: > Merge lworld This pull request has now been integrated. Changeset: 525b20d2 Author: Vicente Romero URL: https://git.openjdk.java.net/valhalla/commit/525b20d284f851758a79ce56dcfddf043acef7da Stats: 1013 lines in 44 files changed: 153 ins; 789 del; 71 mod Merge lworld ------------- PR: https://git.openjdk.java.net/valhalla/pull/683 From vromero at openjdk.java.net Fri Apr 15 16:39:59 2022 From: vromero at openjdk.java.net (Vicente Romero) Date: Fri, 15 Apr 2022 16:39:59 GMT Subject: RFR: addressing several issues in the implementation of universal tvars Message-ID: Last review iteration found several issues in the current implementation, addressing them here ------------- Commit messages: - compiler is issuing multiple warnings for the same issue Changes: https://git.openjdk.java.net/valhalla/pull/684/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=684&range=00 Stats: 24 lines in 3 files changed: 24 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/valhalla/pull/684.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/684/head:pull/684 PR: https://git.openjdk.java.net/valhalla/pull/684 From thihup at gmail.com Tue Apr 19 13:37:39 2022 From: thihup at gmail.com (Thiago Henrique Hupner) Date: Tue, 19 Apr 2022 10:37:39 -0300 Subject: Add note about migrating records to value records Message-ID: I've read the updated JEP (https://openjdk.java.net/jeps/8277163) and one thing I think would be great to include that the migration of records to value records is a breaking change. There is already a section that specifies classes without public constructors can be migrated to value classes without problems, but records are often used with the implicit constructor, and that can go unnoticed when migrating to value records. Regards, Thiago From thartmann at openjdk.java.net Thu Apr 21 12:08:48 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 21 Apr 2022 12:08:48 GMT Subject: [lworld] RFR: 8278390: [lworld] Scalarization of nullable inline types in the calling convention Message-ID: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> This is a large and complex change that extends the calling convention optimization to support nullable types. B2 (value classes) and B3.ref (nullable primitive classes) in arguments and return values are now scalarized, i.e., passed and returned as fields instead of as references. They should now behave like B3.val with the overhead of null-handling. **Major changes:** - Use information from the preload attribute to set up the scalarized calling convention at method link time and support it in the interpreter, adapters, stubs, C1 and C2 on x86_64 and aarch64. - An additional `IsInit` field is passed for each argument to keep track of null. This field will later be re-used to also pass the buffer oop if the value is non-null and buffered (see Limitations section below). - No additional field is required for returns. Instead, the first register is re-used to hold the `IsInit` information. It now contains either (i) all zero if the value is null, (ii) an oop if the value is non-null and heap buffered or (iii) a tagged klass pointer if the value is non-null and not heap buffered. Since the GC wouldn't be happy to observe a value that can be an oop or a tagged klass pointer, we need to clean it up right after the call. We do this by setting it to zero if it's tagged and extracting the IsInit information into another register. Both can then be used by compiled code. If all registers are occupied by the return values, we put the IsInit information into a reserve stack slot (see logic in the `enc_class call_epilog` in the `.ad` files). - Many bug fixes (also unrelated ones), new correctness and IR verification tests. - The long term goal is to get rid of the `InlineTypeNode` / `InlineTypePtrNode` duality in C2. This change makes another step in that direction but there is significant work left. **Limitations:** - Similar to scalarization of B3.val in arguments, the buffer oop is currently not passed as "souvenir". This is non-trivial because it requires some effort to ensure that buffer allocations are not kept alive when "escaping" through arguments at calls and will be addressed by a future change. - Preload attribute mismatches are not yet handled. - Above issues and all the `// TODO 8284443` comments, will be addressed by the follow-up enhancement [JDK-8284443](https://bugs.openjdk.java.net/browse/JDK-8284443). Thanks, Tobias ------------- Commit messages: - More fixes - Fixed null checks on aarch64 - Fixed wrong stack offset on aarch64 - Several bug fixes and corresponding tests - Initial aarch64 port - still seeing some failures. Added more tests and some refactoring - Merged with lworld - Enabled IR verification for a test - Fixed safepoint poll at return and several other ToDos - Enabled IR verification for scalarized returns, added more tests, fixed stack allocation of isInit projection - Restored verifier method - ... and 18 more: https://git.openjdk.java.net/valhalla/compare/9b9365df...7e94b7e1 Changes: https://git.openjdk.java.net/valhalla/pull/685/files Webrev: https://webrevs.openjdk.java.net/?repo=valhalla&pr=685&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8278390 Stats: 3334 lines in 67 files changed: 2828 ins; 202 del; 304 mod Patch: https://git.openjdk.java.net/valhalla/pull/685.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/685/head:pull/685 PR: https://git.openjdk.java.net/valhalla/pull/685 From thartmann at openjdk.java.net Thu Apr 21 14:06:52 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Thu, 21 Apr 2022 14:06:52 GMT Subject: [lworld] RFR: 8278390: [lworld] Scalarization of nullable inline types in the calling convention [v2] In-Reply-To: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> References: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> Message-ID: > This is a large and complex change that extends the calling convention optimization to support nullable types. B2 (value classes) and B3.ref (nullable primitive classes) in arguments and return values are now scalarized, i.e., passed and returned as fields instead of as references. They should now behave like B3.val with the overhead of null-handling. > > **Major changes:** > - Use information from the preload attribute to set up the scalarized calling convention at method link time and support it in the interpreter, adapters, stubs, C1 and C2 on x86_64 and aarch64. > - An additional `IsInit` field is passed for each argument to keep track of null. This field will later be re-used to also pass the buffer oop if the value is non-null and buffered (see Limitations section below). > - No additional field is required for returns. Instead, the first register is re-used to hold the `IsInit` information. It now contains either (i) all zero if the value is null, (ii) an oop if the value is non-null and heap buffered or (iii) a tagged klass pointer if the value is non-null and not heap buffered. Since the GC wouldn't be happy to observe a value that can be an oop or a tagged klass pointer, we need to clean it up right after the call. We do this by setting it to zero if it's tagged and extracting the IsInit information into another register. Both can then be used by compiled code. If all registers are occupied by the return values, we put the IsInit information into a reserve stack slot (see logic in the `enc_class call_epilog` in the `.ad` files). > - Many bug fixes (also unrelated ones), new correctness and IR verification tests. > - The long term goal is to get rid of the `InlineTypeNode` / `InlineTypePtrNode` duality in C2. This change makes another step in that direction but there is significant work left. > > **Limitations:** > - Similar to scalarization of B3.val in arguments, the buffer oop is currently not passed as "souvenir". This is non-trivial because it requires some effort to ensure that buffer allocations are not kept alive when "escaping" through arguments at calls and will be addressed by a future change. > - Preload attribute mismatches are not yet handled. > - Above issues and all the `// TODO 8284443` comments, will be addressed by the follow-up enhancement [JDK-8284443](https://bugs.openjdk.java.net/browse/JDK-8284443). > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: equal -> zero cleanup ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/685/files - new: https://git.openjdk.java.net/valhalla/pull/685/files/7e94b7e1..93970718 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=685&range=01 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=685&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/valhalla/pull/685.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/685/head:pull/685 PR: https://git.openjdk.java.net/valhalla/pull/685 From fparain at openjdk.java.net Thu Apr 21 14:56:58 2022 From: fparain at openjdk.java.net (Frederic Parain) Date: Thu, 21 Apr 2022 14:56:58 GMT Subject: [lworld] RFR: 8278390: [lworld] Scalarization of nullable inline types in the calling convention [v2] In-Reply-To: References: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> Message-ID: On Thu, 21 Apr 2022 14:06:52 GMT, Tobias Hartmann wrote: >> This is a large and complex change that extends the calling convention optimization to support nullable types. B2 (value classes) and B3.ref (nullable primitive classes) in arguments and return values are now scalarized, i.e., passed and returned as fields instead of as references. They should now behave like B3.val with the overhead of null-handling. >> >> **Major changes:** >> - Use information from the preload attribute to set up the scalarized calling convention at method link time and support it in the interpreter, adapters, stubs, C1 and C2 on x86_64 and aarch64. >> - An additional `IsInit` field is passed for each argument to keep track of null. This field will later be re-used to also pass the buffer oop if the value is non-null and buffered (see Limitations section below). >> - No additional field is required for returns. Instead, the first register is re-used to hold the `IsInit` information. It now contains either (i) all zero if the value is null, (ii) an oop if the value is non-null and heap buffered or (iii) a tagged klass pointer if the value is non-null and not heap buffered. Since the GC wouldn't be happy to observe a value that can be an oop or a tagged klass pointer, we need to clean it up right after the call. We do this by setting it to zero if it's tagged and extracting the IsInit information into another register. Both can then be used by compiled code. If all registers are occupied by the return values, we put the IsInit information into a reserve stack slot (see logic in the `enc_class call_epilog` in the `.ad` files). >> - Many bug fixes (also unrelated ones), new correctness and IR verification tests. >> - The long term goal is to get rid of the `InlineTypeNode` / `InlineTypePtrNode` duality in C2. This change makes another step in that direction but there is significant work left. >> >> **Limitations:** >> - Similar to scalarization of B3.val in arguments, the buffer oop is currently not passed as "souvenir". This is non-trivial because it requires some effort to ensure that buffer allocations are not kept alive when "escaping" through arguments at calls and will be addressed by a future change. >> - Preload attribute mismatches are not yet handled. >> - Above issues and all the `// TODO 8284443` comments, will be addressed by the follow-up enhancement [JDK-8284443](https://bugs.openjdk.java.net/browse/JDK-8284443). >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > equal -> zero cleanup Runtime, CI and C1 changes look good to me. Fred src/hotspot/cpu/x86/interp_masm_x86.cpp line 1179: > 1177: > 1178: if (state == atos && InlineTypeReturnedAsFields) { > 1179: // Check if we are returning an inline type and load its fields into registers Suggestion: // Check if we are returning an non-null inline type and load its fields into registers src/hotspot/share/runtime/sharedRuntime.cpp line 2975: > 2973: InlineKlass* vk = ss.as_inline_klass(holder); > 2974: // TODO 8284443 Mismatch handling, we need to check parent method args (look at klassVtable::needs_new_vtable_entry) > 2975: if (vk != NULL && (bt == T_PRIMITIVE_OBJECT || holder->is_preload_class(vk->name())) && Limiting argument scalarization to value classes present in the PreLoad attribute could lead to missed opportunities of scalarize if the class was loaded but not in the attribute (incomplete or missing PreLoad attributer case). The calling convention could instead look at which classes are loaded with no consideration to what triggered the loading. This would force overriding methods to look directly at the calling convention of the overridden method instead of looking at its context (lines 2861, 2882). But this is a work that should be done when dealing with calling conventions mismatches (JDK-8284443). ------------- Marked as reviewed by fparain (Committer). PR: https://git.openjdk.java.net/valhalla/pull/685 From thartmann at openjdk.java.net Fri Apr 22 09:26:52 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 22 Apr 2022 09:26:52 GMT Subject: [lworld] RFR: 8278390: [lworld] Scalarization of nullable inline types in the calling convention [v3] In-Reply-To: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> References: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> Message-ID: > This is a large and complex change that extends the calling convention optimization to support nullable types. B2 (value classes) and B3.ref (nullable primitive classes) in arguments and return values are now scalarized, i.e., passed and returned as fields instead of as references. They should now behave like B3.val with the overhead of null-handling. > > **Major changes:** > - Use information from the preload attribute to set up the scalarized calling convention at method link time and support it in the interpreter, adapters, stubs, C1 and C2 on x86_64 and aarch64. > - An additional `IsInit` field is passed for each argument to keep track of null. This field will later be re-used to also pass the buffer oop if the value is non-null and buffered (see Limitations section below). > - No additional field is required for returns. Instead, the first register is re-used to hold the `IsInit` information. It now contains either (i) all zero if the value is null, (ii) an oop if the value is non-null and heap buffered or (iii) a tagged klass pointer if the value is non-null and not heap buffered. Since the GC wouldn't be happy to observe a value that can be an oop or a tagged klass pointer, we need to clean it up right after the call. We do this by setting it to zero if it's tagged and extracting the IsInit information into another register. Both can then be used by compiled code. If all registers are occupied by the return values, we put the IsInit information into a reserve stack slot (see logic in the `enc_class call_epilog` in the `.ad` files). > - Many bug fixes (also unrelated ones), new correctness and IR verification tests. > - The long term goal is to get rid of the `InlineTypeNode` / `InlineTypePtrNode` duality in C2. This change makes another step in that direction but there is significant work left. > > **Limitations:** > - Similar to scalarization of B3.val in arguments, the buffer oop is currently not passed as "souvenir". This is non-trivial because it requires some effort to ensure that buffer allocations are not kept alive when "escaping" through arguments at calls and will be addressed by a future change. > - Preload attribute mismatches are not yet handled. > - Above issues and all the `// TODO 8284443` comments, will be addressed by the follow-up enhancement [JDK-8284443](https://bugs.openjdk.java.net/browse/JDK-8284443). > > Thanks, > Tobias Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: Comment fix ------------- Changes: - all: https://git.openjdk.java.net/valhalla/pull/685/files - new: https://git.openjdk.java.net/valhalla/pull/685/files/93970718..a093da38 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=valhalla&pr=685&range=02 - incr: https://webrevs.openjdk.java.net/?repo=valhalla&pr=685&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/valhalla/pull/685.diff Fetch: git fetch https://git.openjdk.java.net/valhalla pull/685/head:pull/685 PR: https://git.openjdk.java.net/valhalla/pull/685 From thartmann at openjdk.java.net Fri Apr 22 09:26:54 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 22 Apr 2022 09:26:54 GMT Subject: [lworld] RFR: 8278390: [lworld] Scalarization of nullable inline types in the calling convention [v2] In-Reply-To: References: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> Message-ID: On Thu, 21 Apr 2022 14:06:52 GMT, Tobias Hartmann wrote: >> This is a large and complex change that extends the calling convention optimization to support nullable types. B2 (value classes) and B3.ref (nullable primitive classes) in arguments and return values are now scalarized, i.e., passed and returned as fields instead of as references. They should now behave like B3.val with the overhead of null-handling. >> >> **Major changes:** >> - Use information from the preload attribute to set up the scalarized calling convention at method link time and support it in the interpreter, adapters, stubs, C1 and C2 on x86_64 and aarch64. >> - An additional `IsInit` field is passed for each argument to keep track of null. This field will later be re-used to also pass the buffer oop if the value is non-null and buffered (see Limitations section below). >> - No additional field is required for returns. Instead, the first register is re-used to hold the `IsInit` information. It now contains either (i) all zero if the value is null, (ii) an oop if the value is non-null and heap buffered or (iii) a tagged klass pointer if the value is non-null and not heap buffered. Since the GC wouldn't be happy to observe a value that can be an oop or a tagged klass pointer, we need to clean it up right after the call. We do this by setting it to zero if it's tagged and extracting the IsInit information into another register. Both can then be used by compiled code. If all registers are occupied by the return values, we put the IsInit information into a reserve stack slot (see logic in the `enc_class call_epilog` in the `.ad` files). >> - Many bug fixes (also unrelated ones), new correctness and IR verification tests. >> - The long term goal is to get rid of the `InlineTypeNode` / `InlineTypePtrNode` duality in C2. This change makes another step in that direction but there is significant work left. >> >> **Limitations:** >> - Similar to scalarization of B3.val in arguments, the buffer oop is currently not passed as "souvenir". This is non-trivial because it requires some effort to ensure that buffer allocations are not kept alive when "escaping" through arguments at calls and will be addressed by a future change. >> - Preload attribute mismatches are not yet handled. >> - Above issues and all the `// TODO 8284443` comments, will be addressed by the follow-up enhancement [JDK-8284443](https://bugs.openjdk.java.net/browse/JDK-8284443). >> >> Thanks, >> Tobias > > Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: > > equal -> zero cleanup Thanks for the review, Fred! ------------- PR: https://git.openjdk.java.net/valhalla/pull/685 From thartmann at openjdk.java.net Fri Apr 22 09:26:56 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Fri, 22 Apr 2022 09:26:56 GMT Subject: [lworld] RFR: 8278390: [lworld] Scalarization of nullable inline types in the calling convention [v2] In-Reply-To: References: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com>

Message-ID: On Thu, 21 Apr 2022 14:35:32 GMT, Frederic Parain wrote: >> Tobias Hartmann has updated the pull request incrementally with one additional commit since the last revision: >> >> equal -> zero cleanup > > src/hotspot/cpu/x86/interp_masm_x86.cpp line 1179: > >> 1177: >> 1178: if (state == atos && InlineTypeReturnedAsFields) { >> 1179: // Check if we are returning an inline type and load its fields into registers > > Suggestion: > // Check if we are returning an non-null inline type and load its fields into registers Thanks, fixed. > src/hotspot/share/runtime/sharedRuntime.cpp line 2975: > >> 2973: InlineKlass* vk = ss.as_inline_klass(holder); >> 2974: // TODO 8284443 Mismatch handling, we need to check parent method args (look at klassVtable::needs_new_vtable_entry) >> 2975: if (vk != NULL && (bt == T_PRIMITIVE_OBJECT || holder->is_preload_class(vk->name())) && > > Limiting argument scalarization to value classes present in the PreLoad attribute could lead to missed opportunities of scalarize if the class was loaded but not in the attribute (incomplete or missing PreLoad attributer case). The calling convention could instead look at which classes are loaded with no consideration to what triggered the loading. This would force overriding methods to look directly at the calling convention of the overridden method instead of looking at its context (lines 2861, 2882). > But this is a work that should be done when dealing with calling conventions mismatches (JDK-8284443). Yes, good point. As we discussed off-thread, I'll take care of this with JDK-8284443. ------------- PR: https://git.openjdk.java.net/valhalla/pull/685 From tanksherman27 at gmail.com Sun Apr 24 14:19:45 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Sun, 24 Apr 2022 22:19:45 +0800 Subject: Forcefully inline reference types Message-ID: Hi all, After some discussion with lilliput-dev about the possibility of removing the entire Mark Word, I'm wondering if being able to forcefully inline value and identity objects when they're instantiated could have any merit or benefit to be looked at in Valhalla. The idea came after the realization that to fully omit the Mark Word the GC bits in the header would also have to be dealt with, something which cannot be done by simply not having them in the header given that this may cause GC related performance issues. The discussed alternative was to not have GC support for certain objects at all, but that would require it to be able to take advantage of other memory freeing operations (Eg Popping off a stack frame, being inlined inside another object to be freed when the containing object is GC'd). To my knowledge regular objects can already be inlined by HotSpot via Escape Analysis, would it then be worth discussing to re-use the older "inline" keyword from Valhalla to allow control over this from the source level as well? (With the limitation that the object cannot escape its scope, and only copies of it may be made otherwise, something that may in turn require semantics for choosing to pass by value or reference) There are other issues with locking and identity hashes that relate to this, but that's probably better discussed back at lilliput-dev if this happens to be something we can look into best regards, Julian From brian.goetz at oracle.com Sun Apr 24 15:15:30 2022 From: brian.goetz at oracle.com (Brian Goetz) Date: Sun, 24 Apr 2022 15:15:30 +0000 Subject: Forcefully inline reference types In-Reply-To: References: Message-ID: <9AA55B60-ED6A-466C-B2DF-25542EC65378@oracle.com> Can you elaborate what you mean by ?forcefully inline?, as different from the existing mission of Valhalla? > On Apr 24, 2022, at 10:19 AM, Julian Waters wrote: > > Hi all, > > After some discussion with lilliput-dev about the possibility of removing > the entire Mark Word, I'm wondering if being able to forcefully inline > value and identity objects when they're instantiated could have any merit > or benefit to be looked at in Valhalla. The idea came after the realization > that to fully omit the Mark Word the GC bits in the header would also have > to be dealt with, something which cannot be done by simply not having them > in the header given that this may cause GC related performance issues. The > discussed alternative was to not have GC support for certain objects at > all, but that would require it to be able to take advantage of other memory > freeing operations (Eg Popping off a stack frame, being inlined inside > another object to be freed when the containing object is GC'd). To my > knowledge regular objects can already be inlined by HotSpot via Escape > Analysis, would it then be worth discussing to re-use the older "inline" > keyword from Valhalla to allow control over this from the source level as > well? (With the limitation that the object cannot escape its scope, and > only copies of it may be made otherwise, something that may in turn require > semantics for choosing to pass by value or reference) > > There are other issues with locking and identity hashes that relate to > this, but that's probably better discussed back at lilliput-dev if this > happens to be something we can look into > > best regards, > Julian From tanksherman27 at gmail.com Mon Apr 25 03:43:15 2022 From: tanksherman27 at gmail.com (Julian Waters) Date: Mon, 25 Apr 2022 11:43:15 +0800 Subject: Forcefully inline reference types In-Reply-To: <9AA55B60-ED6A-466C-B2DF-25542EC65378@oracle.com> References: <9AA55B60-ED6A-466C-B2DF-25542EC65378@oracle.com> Message-ID: Possibly something like inline Object object = new Object(); would force any reference type (value and identity objects) it's used on to always be inlined/allocated directly where it's instantiated (Eg in a scope/stack frame or within another object) instead of initially being stored on the heap and only stack allocated/inlined in another object after optimizations. Value objects were after all introduced for the purpose of allowing HotSpot to inline them more effectively than Escape Analysis currently can with regular objects, but to my knowledge this only happens when it reaches C2, and it's occurred to me that there hasn't really been the option to explicitly inline an object directly at the source level rather than wait for HotSpot to do so automatically (the latter also needs checks at runtime lest the eager optimization be incorrect), though of course this would require new restrictions to be placed on anything with the "inline" modifier on it. But we might get extra benefits by doing so since we'll know from the start that the particular object is always allocated directly where it's created and never supposed to have extra space allocated on the heap for it, which lets Lilliput omit GC support with that guarantee, but Valhalla might also capitalize on this as well best regards, Julian On Sun, Apr 24, 2022 at 11:15 PM Brian Goetz wrote: > Can you elaborate what you mean by ?forcefully inline?, as different from > the existing mission of Valhalla? > > > On Apr 24, 2022, at 10:19 AM, Julian Waters > wrote: > > > > Hi all, > > > > After some discussion with lilliput-dev about the possibility of removing > > the entire Mark Word, I'm wondering if being able to forcefully inline > > value and identity objects when they're instantiated could have any merit > > or benefit to be looked at in Valhalla. The idea came after the > realization > > that to fully omit the Mark Word the GC bits in the header would also > have > > to be dealt with, something which cannot be done by simply not having > them > > in the header given that this may cause GC related performance issues. > The > > discussed alternative was to not have GC support for certain objects at > > all, but that would require it to be able to take advantage of other > memory > > freeing operations (Eg Popping off a stack frame, being inlined inside > > another object to be freed when the containing object is GC'd). To my > > knowledge regular objects can already be inlined by HotSpot via Escape > > Analysis, would it then be worth discussing to re-use the older "inline" > > keyword from Valhalla to allow control over this from the source level as > > well? (With the limitation that the object cannot escape its scope, and > > only copies of it may be made otherwise, something that may in turn > require > > semantics for choosing to pass by value or reference) > > > > There are other issues with locking and identity hashes that relate to > > this, but that's probably better discussed back at lilliput-dev if this > > happens to be something we can look into > > > > best regards, > > Julian > > From thartmann at openjdk.java.net Mon Apr 25 06:38:01 2022 From: thartmann at openjdk.java.net (Tobias Hartmann) Date: Mon, 25 Apr 2022 06:38:01 GMT Subject: [lworld] Integrated: 8278390: [lworld] Scalarization of nullable inline types in the calling convention In-Reply-To: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> References: <69F9sLGbniye_VaCaxgCIgVnbPGG5Ck9tZB4KcW5R_U=.9225e064-c4e1-42dc-bf56-daf7692c656b@github.com> Message-ID: On Thu, 21 Apr 2022 12:01:49 GMT, Tobias Hartmann wrote: > This is a large and complex change that extends the calling convention optimization to support nullable types. B2 (value classes) and B3.ref (nullable primitive classes) in arguments and return values are now scalarized, i.e., passed and returned as fields instead of as references. They should now behave like B3.val with the overhead of null-handling. > > **Major changes:** > - Use information from the preload attribute to set up the scalarized calling convention at method link time and support it in the interpreter, adapters, stubs, C1 and C2 on x86_64 and aarch64. > - An additional `IsInit` field is passed for each argument to keep track of null. This field will later be re-used to also pass the buffer oop if the value is non-null and buffered (see Limitations section below). > - No additional field is required for returns. Instead, the first register is re-used to hold the `IsInit` information. It now contains either (i) all zero if the value is null, (ii) an oop if the value is non-null and heap buffered or (iii) a tagged klass pointer if the value is non-null and not heap buffered. Since the GC wouldn't be happy to observe a value that can be an oop or a tagged klass pointer, we need to clean it up right after the call. We do this by setting it to zero if it's tagged and extracting the IsInit information into another register. Both can then be used by compiled code. If all registers are occupied by the return values, we put the IsInit information into a reserve stack slot (see logic in the `enc_class call_epilog` in the `.ad` files). > - Many bug fixes (also unrelated ones), new correctness and IR verification tests. > - The long term goal is to get rid of the `InlineTypeNode` / `InlineTypePtrNode` duality in C2. This change makes another step in that direction but there is significant work left. > > **Limitations:** > - Similar to scalarization of B3.val in arguments, the buffer oop is currently not passed as "souvenir". This is non-trivial because it requires some effort to ensure that buffer allocations are not kept alive when "escaping" through arguments at calls and will be addressed by a future change. > - Preload attribute mismatches are not yet handled. > - Above issues and all the `// TODO 8284443` comments, will be addressed by the follow-up enhancement [JDK-8284443](https://bugs.openjdk.java.net/browse/JDK-8284443). > > Thanks, > Tobias This pull request has now been integrated. Changeset: 8fa17feb Author: Tobias Hartmann URL: https://git.openjdk.java.net/valhalla/commit/8fa17febe332bfad2f125bbc9b429279214b3248 Stats: 3335 lines in 67 files changed: 2828 ins; 202 del; 305 mod 8278390: [lworld] Scalarization of nullable inline types in the calling convention Reviewed-by: fparain ------------- PR: https://git.openjdk.java.net/valhalla/pull/685 From mariell.hoversholm at paf.com Mon Apr 25 10:04:52 2022 From: mariell.hoversholm at paf.com (Mariell Hoversholm) Date: Mon, 25 Apr 2022 12:04:52 +0200 Subject: Forcefully inline reference types In-Reply-To: References: <9AA55B60-ED6A-466C-B2DF-25542EC65378@oracle.com> Message-ID: Hi Julian, I'm not fully sure I understand what you mean by inlining the instantiation point. Do you want the given `object` to be allocated on the stack when it is "inlined", or do you want it to act somewhat like this?: inline Object object = new Object(); new OtherClass(object); OtherClass(Object object) {} // being the same as: Supplier