On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. Solution is to use bit flip on the actual index (and rename
>> the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and
>> 0 the de
On Mon, 15 Jul 2024 11:29:49 GMT, Rémi Forax wrote:
> > This is what I was thinking of as well. close() on a shared arena can be
> > called by any thread, so it would be possible to have an executor service
> > with 1-n threads that is dedicated to closing memory.
>
> This delays both the clos
On Mon, 15 Jul 2024 13:09:21 GMT, Maurizio Cimadamore
wrote:
> > Even with `arrayElementVarHandle` it's about the same
>
> This is very odd, and I don't have a good explanation as to why that is the
> case. What does the baseline (confined arena) look like for
> `arrayElementVarHandle` ?
Pre
On Mon, 15 Jul 2024 12:14:52 GMT, Maurizio Cimadamore
wrote:
> Ah! I had `arrayElementVarHandle` in mind - maybe you can try that?
Even with `arrayElementVarHandle` it's about the same
-
PR Comment: https://git.openjdk.org/jdk/pull/20158#issuecomment-2228425705
On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
On Mon, 15 Jul 2024 11:33:30 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
us/op
> ConcurrentClose.sharedAccess6 avgt 10 386.697 ± 59.170 us/op
> ConcurrentClose.sharedAccess5 avgt 10 291.157 ± 7.023 us/op
> ConcurrentClose.sharedAccess4 avgt 10 209.178 ± 5.802 us/op
> ConcurrentClose.sharedAccess1 avgt
On Mon, 15 Jul 2024 09:02:29 GMT, Uwe Schindler wrote:
> Of course we can do that in a separate thread (this is my idea how to improve
> the closes in lucene).
This is what I was thinking of as well. `close()` on a shared arena can be
called by any thread, so it would be possible to have an ex
On Mon, 15 Jul 2024 08:41:38 GMT, Doug Simon wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> track has_scoped_access for compiled methods
>
> src/hotspot/share/jvmci/jvmciRun
On Sat, 13 Jul 2024 15:28:57 GMT, Erik Österlund wrote:
> @dougxc might want to have a look at Graal support for this one.
Yes, I conservatively implemented `has_scoped_access()` for Graal (see
`jvmciRuntime.cpp` changes). It won't regress anything, but there's still an
opportunity for improve
On Fri, 12 Jul 2024 20:59:26 GMT, Jorn Vernee wrote:
>> This PR limits the number of cases in which we deoptimize frames when
>> closing a shared Arena. The initial intent of this was to improve the
>> performance of shared arena closure in cases where a lot of threads are
On Fri, 12 Jul 2024 13:57:23 GMT, Jorn Vernee wrote:
> This PR limits the number of cases in which we deoptimize frames when closing
> a shared Arena. The initial intent of this was to improve the performance of
> shared arena closure in cases where a lot of threads are acce
sharedAccess6 avgt 10 386.697 ± 59.170 us/op
> ConcurrentClose.sharedAccess5 avgt 10 291.157 ± 7.023 us/op
> ConcurrentClose.sharedAccess4 avgt 10 209.178 ± 5.802 us/op
> ConcurrentClose.sharedAccess1 avgt 1052.042 ± 0.630 us/op
> ConcurrentClo
This PR limits the number of cases in which we deoptimize frames when closing a
shared Arena. The initial intent of this was to improve the performance of
shared arena closure in cases where a lot of threads are accessing and closing
shared arenas at the same time (see attached benchmark), but u
On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 10 Jul 2024 16:08:51 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [c80e2eb3](https://github.com/openjdk/jdk/commit/c80e2eb35c4eb03f17a2a31e979e5c369453e203)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
reviewed by Jorn Vernee and Maurizio Cimadamore.
This is a P4 doc-only change, which is permitted in RDP1:
https://openjdk.org/jeps/3#Quick-reference
This change should also make it possible to cleanly backport:
https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef
Thanks
reviewed by Jorn Vernee and Maurizio Cimadamore.
Thanks!
-
Commit messages:
- Backport 6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef
Changes: https://git.openjdk.org/jdk/pull/20119/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20119&range=00
Issue: https://bugs.ope
On Sat, 29 Jun 2024 06:26:57 GMT, Alan Bateman wrote:
> I assume you'll create follow-up issues in JBS for the Class-Path attribute,
> improvement the usage/help output to replace the "Path"/"String" types.
I've filed: https://bugs.openjdk.org/browse/JDK-8335877 and
https://bugs.openjdk.org/br
On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>&
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The
On Fri, 5 Jul 2024 13:44:46 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>&
On Thu, 4 Jul 2024 06:22:31 GMT, Hannes Greule wrote:
>> Similar to how `MethodHandle#invoke(Exact)` methods are already handled,
>> this change adds special casing for `VarHandle.{access-mode}` methods.
>>
>> The exception message is less exact, but I think that's acceptable.
>
> Hannes Greule
On Fri, 5 Jul 2024 14:01:59 GMT, Per Minborg wrote:
>> This PR proposes to retain the read-only state when any of the
>> `MemorySegment::reinterpret` methods is called.
>>
>> Previously, the read-only state was lost and the returned `MemorySegment`
>> was always writable regardless of the orig
On Wed, 3 Jul 2024 19:11:34 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
>> line 228:
>>
>>> 226: mtype = mt;
>>> 227: } catch (TypeNotPresentException ex) {
>>> 228: throw (ClassNotFoundException) ex.getCaus
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request with a new target base due to a merge
or a rebase. The incremental webrev excludes the unrelated changes brought in
by t
On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote:
> Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc`
> specification.
src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line
228:
> 226: mtype = mt;
> 227: } catch (TypeNotPres
On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote:
> Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc`
> specification.
Marked as reviewed by jvernee (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/19991#pullrequestreview-2156417137
On Wed, 3 Jul 2024 12:04:37 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java
>> line 226:
>>
>>> 224: }
>>> 225: });
>>> 226: mtype = mt;
>>
>> Can you drop this intermediate variable, and just assign to
On Tue, 2 Jul 2024 16:20:54 GMT, Chen Liang wrote:
> Simple fix for `MethodTypeDescImpl`'s violation of `resolveConstantDesc`
> specification.
src/java.base/share/classes/jdk/internal/constant/MethodTypeDescImpl.java line
226:
> 224: }
> 225: });
> 226:
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
ofInvokeInstruction
-
Changes:
- all: htt
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
use instance resolveAndBind + use junit in tests
---
On Fri, 28 Jun 2024 16:47:27 GMT, Alan Bateman wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> de-dupe on path, not module name
>
> src/jdk.jdeps/share/classes/com/sun/tools/jnativesca
On Thu, 27 Jun 2024 12:27:26 GMT, Claes Redestad wrote:
> This PR attains a speed-up on some microbenchmarks by simplifying how we
> build up the MH combinator tree shape
> (only use prependers with prefix, always add a suffix to the newArray
> combinator), then simplifying/inlining some of the
On Mon, 24 Jun 2024 12:57:39 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
de-dupe on path, not module name
-
Changes:
On Thu, 20 Jun 2024 17:25:33 GMT, Alan Bateman wrote:
>> Something like that yes
>
> An altermative is to use ResolvedModule::reference to get a ModuleReference,
> then use its open method to open the contents of the module to get a
> ModuleReader. That will give you a stream over the names of
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with three additional
commits since the last revision:
- Add support for module directories + class path dir
On Fri, 21 Jun 2024 18:38:07 GMT, Jorn Vernee wrote:
>> test/langtools/tools/jnativescan/TestJNativeScan.java line 174:
>>
>>> 172: "-add-modules",
>>> "org.singlejar,org.myapp",
>>> 173:
On Fri, 21 Jun 2024 18:31:00 GMT, Jan Lahoda wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> add extra test for missing root modules
>
> src/jdk.jdeps/share/classes/com/sun/tool
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
add extra test for missing root modules
---
On Thu, 20 Jun 2024 12:11:25 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
review comments Alan
-
Changes:
- all: htt
On Thu, 20 Jun 2024 16:13:04 GMT, Alan Bateman wrote:
> Another thing is that using joptsimple gives up a bit of control, e.g. the
> help output shows the parameter for --class-path as `` where the java
> launcher and other tools will show "path" or "class path". Same thing with
> `--release`
On Thu, 20 Jun 2024 12:51:22 GMT, Evemose wrote:
> wouldn't it be better to create one uniform tool
See my reply here:
https://github.com/openjdk/jdk/pull/19774#issuecomment-2179078565
-
PR Comment: https://git.openjdk.org/jdk/pull/19774#issuecomment-2180653743
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
update man page header to be consisten with the others
---
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
man page review comments
-
Changes:
- al
On Wed, 19 Jun 2024 21:35:07 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativesc
On Thu, 20 Jun 2024 11:42:04 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/man/jnativescan.1 line 127:
>>
>>> 125: This option should be set to the version of the runtime under which the
>>> 126: application is eventually intended to be run.
>>> 127: If
On Wed, 19 Jun 2024 21:30:49 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - review comments
>> - add man page
>
> src/jdk.jdeps/share/man/jnativesc
On Wed, 19 Jun 2024 18:57:43 GMT, Jorn Vernee wrote:
>> I can do that, but I think this will always be a bit awkward since these
>> types don't have a common super type that exposes the needed information.
>
>> these types don't have a common super type that exp
On Wed, 19 Jun 2024 21:13:33 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
On Wed, 19 Jun 2024 18:02:08 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/ClassResolver.java
>> line 126:
>>
>>> 124:
>>> 125: private static Map packageToSystemModule() {
>>> 126:
On Wed, 19 Jun 2024 19:00:22 GMT, Jorn Vernee wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with two additional
commits since the last revision:
- review comments
- add man page
-
Changes:
On Wed, 19 Jun 2024 17:41:36 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Update src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/Main.java
>>
On Wed, 19 Jun 2024 17:45:14 GMT, Jorn Vernee wrote:
>> src/jdk.jdeps/share/classes/com/sun/tools/jnativescan/RestrictedMethodFinder.java
>> line 120:
>>
>>> 118: Optional info =
>>> systemClassResolver.lookup(methodRef.owner());
>
On Wed, 19 Jun 2024 18:09:15 GMT, Jorn Vernee wrote:
> these types don't have a common super type that exposes the needed information
No wait, they actually do :) That's just `MemberRefEntry`.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19774#discussion_r1646604479
x27;s libclang bindings, which use the FFM API,
> and thus has a lot of references to `@Restricted` methods.
> - tier 1-3
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Update src/jdk.jdeps/share/classes/com/sun
On Wed, 19 Jun 2024 17:28:23 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 17:53:12 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 17:30:08 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 17:16:54 GMT, Maurizio Cimadamore
wrote:
>> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
>> code that accesses native functionality. Currently this includes `native`
>> method declarations, and methods marked with `@Restricted`.
>>
>> The too
On Wed, 19 Jun 2024 14:30:23 GMT, Roger Riggs wrote:
> One more tool. or... Could this be coalesced into a tool that does deprscan
> and restricted methods, and other "lint" type checks? I might go so far as to
> suggest it be extensible and accept patterns or regular expressions for
> matchin
This PR adds a new JDK tool, called `jnativescan`, that can be used to find
code that accesses native functionality. Currently this includes `native`
method declarations, and methods marked with `@Restricted`.
The tool accepts a list of class path and module path entries through
`--class-path`
On Tue, 18 Jun 2024 16:30:37 GMT, Jorn Vernee wrote:
> This PR adds a new JDK tool, called `jnativescan`, that can be used to find
> code that accesses native functionality. Currently this includes `native`
> method declarations, and methods marked with `@Restricted`.
>
> The
On Tue, 11 Jun 2024 12:22:24 GMT, Per Minborg wrote:
>> This PR proposes to explicitly state that returned segments form the
>> `asSlice` and `reinterpret` method share memory regions with `this` memory
>> segment.
>>
>> Note: The term "subset" means a true subset or the same set.
>
> Per Min
On Tue, 11 Jun 2024 09:18:23 GMT, Per Minborg wrote:
> If a segment is reinterpreted to be larger than this segment, then the extra
> memory is not a part of this segment's backing part.
Another way to think about this is: a segment's backing region can be larger or
smaller than the bounds spe
On Mon, 10 Jun 2024 17:09:27 GMT, Jorn Vernee wrote:
> The term 'subset' doesn't feel right to me here, since we're only talking
> about a single memory region (not a set of memory region**s**). I suggest
> 'sub-region' instead.
Actually, nvm, that d
On Mon, 10 Jun 2024 15:45:07 GMT, Per Minborg wrote:
> This PR proposes to explicitly state that returned segments form the
> `asSlice` and `reinterpret` method share memory regions with `this` memory
> segment.
>
> Note: The term "subset" means a true subset or the same set.
The term 'subse
On Mon, 10 Jun 2024 15:30:39 GMT, Per Minborg wrote:
>> This PR proposes to retain the read-only state when any of the
>> `MemorySegment::reinterpret` methods is called.
>>
>> Previously, the read-only state was lost and the returned `MemorySegment`
>> was always writable regardless of the ori
On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad wrote:
>> This PR refactors type matching in BootstrapMethodInvoker and adds a few
>> types, seeking to improve bootstrap overheads of some ConstantBootstraps and
>> in particular the ProxyGenerator condys generated for e.g. annotation
>> proxies
On Fri, 7 Jun 2024 18:58:36 GMT, Claes Redestad wrote:
>> This PR refactors type matching in BootstrapMethodInvoker and adds a few
>> types, seeking to improve bootstrap overheads of some ConstantBootstraps and
>> in particular the ProxyGenerator condys generated for e.g. annotation
>> proxies
On Mon, 10 Jun 2024 07:56:03 GMT, Claes Redestad wrote:
>> Claes Redestad has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adress review comments, add ConstantBootstraps#invoke to list of
>> recognized type signatures
>
> Sure. If you ca
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/p
On Fri, 7 Jun 2024 12:12:44 GMT, Claes Redestad wrote:
> This PR refactors type matching in BootstrapMethodInvoker and adds a few
> types, seeking to improve bootstrap overheads of some ConstantBootstraps and
> in particular the ProxyGenerator condys generated for e.g. annotation proxies
> sin
On Fri, 7 Jun 2024 12:12:44 GMT, Claes Redestad wrote:
> This PR refactors type matching in BootstrapMethodInvoker and adds a few
> types, seeking to improve bootstrap overheads of some ConstantBootstraps and
> in particular the ProxyGenerator condys generated for e.g. annotation proxies
> sin
On Thu, 6 Jun 2024 10:48:51 GMT, Aleksey Shipilev wrote:
>> These 4 tests were failing due to an incompatibility with jcstress. They
>> were problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>>
>> Now that jcstress has been updated
>> (https://github.com/openjdk/jdk/pull/193
On Fri, 7 Jun 2024 12:35:37 GMT, Chen Liang wrote:
>> In java.base, especially in bytecode generators, we have many different
>> methods converting known valid Class and MethodType into ClassDesc and
>> MethodTypeDesc. These conversions should be consolidated into the same
>> utility method fo
On Thu, 6 Jun 2024 19:24:14 GMT, Chen Liang wrote:
>> In java.base, especially in bytecode generators, we have many different
>> methods converting known valid Class and MethodType into ClassDesc and
>> MethodTypeDesc. These conversions should be consolidated into the same
>> utility method fo
On Thu, 6 Jun 2024 10:48:51 GMT, Aleksey Shipilev wrote:
> I think only Oracle CIs run these tests through jtreg wrappers?
We do run them in our CI. Not sure who else runs them that way.
-
PR Comment: https://git.openjdk.org/jdk/pull/19565#issuecomment-2152799029
These 4 tests were failing due to an incompatibility with jcstress. They were
problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
Now that jcstress has been updated (https://github.com/openjdk/jdk/pull/19332)
with the relevant fix (https://github.com/openjdk/jcstress/pull/147),
On Mon, 3 Jun 2024 19:36:58 GMT, Vladimir Ivanov wrote:
>> JVM routinely installs loader constraints for unloaded signature classes
>> when method resolution takes place. MethodHandle resolution took a different
>> route and eagerly resolves signature classes instead (see
>> `java.lang.invoke.
On Fri, 31 May 2024 16:18:33 GMT, Maurizio Cimadamore
wrote:
>> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`.
>> The cache was moved to `ValueLayouts::varHandle` as part of
>> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we
>> want to opt
On Thu, 30 May 2024 16:15:22 GMT, Maurizio Cimadamore
wrote:
> This PR restores a var handle cache in `Utils::makeSegmentViewVarHandle`. The
> cache was moved to `ValueLayouts::varHandle` as part of
> [pull/19251](https://git.openjdk.org/jdk/pull/19251), on the basis that we
> want to optimiz
On Mon, 27 May 2024 20:55:29 GMT, Pavel Rappo wrote:
>> Please review this PR, which supersedes a now withdrawn
>> https://github.com/openjdk/jdk/pull/14831.
>>
>> This PR replaces `ArraysSupport.vectorizedHashCode` with a set of more
>> user-friendly methods. Here's a summary:
>>
>> - Made t
On Tue, 21 May 2024 10:20:27 GMT, Maurizio Cimadamore
wrote:
>> When creating a nested memory access var handle, we ensure that the segment
>> is accessed at the correct alignment for the root layout being accessed. But
>> we do not ensure that the segment has at least the size of the accessed
On Tue, 21 May 2024 18:02:45 GMT, Vladimir Ivanov wrote:
> I can definitely name it differently (e.g, ensureTypeVisible), but making a
> separate class loading pass across signature classes doesn't make much sense.
Ok, in that case I suggest also renaming `MemberName::checkForTypeAlias`, maybe
On Mon, 20 May 2024 21:29:20 GMT, Vladimir Ivanov wrote:
> JVM routinely installs loader constraints for unloaded signature classes when
> method resolution takes place. MethodHandle resolution took a different route
> and eagerly resolves signature classes instead (see
> `java.lang.invoke.Mem
On Fri, 26 Apr 2024 11:51:51 GMT, Claes Redestad wrote:
>> This PR makes ClassDesc.ofDescriptor return the shared constant for
>> primitive descriptor strings ("I" etc..), and leverages this further by
>> refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate
>> substring for
On Fri, 26 Apr 2024 11:49:19 GMT, Claes Redestad wrote:
> > Does removing the explicit null checks make that much difference for
> > performance? They are kind of nice for clarity.
>
> It helps startup at least. The redundant array depth check mattered a bit for
> peak performance, but not muc
On Fri, 26 Apr 2024 10:54:49 GMT, Claes Redestad wrote:
>> This PR makes ClassDesc.ofDescriptor return the shared constant for
>> primitive descriptor strings ("I" etc..), and leverages this further by
>> refactoring `MethodTypeDescImpl.ofDescriptor` to avoid the intermediate
>> substring for
On Fri, 19 Apr 2024 19:18:13 GMT, Scott Gibbons wrote:
>> src/hotspot/share/opto/runtime.cpp line 786:
>>
>>> 784: fields[argp++] = TypePtr::NOTNULL;// dest
>>> 785: fields[argp++] = TypeLong::LONG; // size
>>> 786: fields[argp++] = Type::HALF; // size
>>
>> Since the si
On Fri, 19 Apr 2024 16:25:28 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Tue, 16 Apr 2024 00:04:15 GMT, Scott Gibbons wrote:
>> This code makes an intrinsic stub for `Unsafe::setMemory` for x86_64. See
>> [this PR](https://github.com/openjdk/jdk/pull/16760) for discussion around
>> this change.
>>
>> Overall, making this an intrinsic improves overall performanc
On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg wrote:
>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
>> symbol has been found by the lookup or not (which enables composition of
>> symbol lookups), many clients end up just calling `Optional::get`, or
>> `Optional
On Wed, 17 Apr 2024 08:46:59 GMT, Adam Sotona wrote:
> Current implementation of `LambdaMetafactory` does not allow to use lambdas
> in hidden classes. Invocation throws `NoClassDefFoundError` instead.
>
> This patch includes lambda implementation in a hidden class under the special
> handling
On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg wrote:
>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a
>> symbol has been found by the lookup or not (which enables composition of
>> symbol lookups), many clients end up just calling `Optional::get`, or
>> `Optional
On Tue, 16 Apr 2024 07:09:55 GMT, Per Minborg wrote:
> This PR proposes to update the javadocs for `ValueLayout.JAVA_LONG` and
> `ValueLayout.JAVA_DOUBLE` to reflect the changes made in
> https://bugs.openjdk.org/browse/JDK-8326172 (we forgot to update the docs
> when that issue was fixed)
M
On Mon, 15 Apr 2024 22:22:38 GMT, Sandhya Viswanathan
wrote:
>> Scott Gibbons has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix memory mark after sync to upstream
>
> src/hotspot/cpu/x86/stubGenerator_x86_64_arraycopy.cpp line 2686:
>
101 - 200 of 949 matches
Mail list logo
