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
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
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: https://
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
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
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:
- all: ht
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 exposes the n
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
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:
- al
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
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/tool
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
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
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
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
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
>
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`.
>
> T
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
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
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 doesn't work for `reinterpr
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
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
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
>>
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
>>
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
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
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
>
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
>
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
>>
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
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
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
>>
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
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
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
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
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
>
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
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
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
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
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
>>
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
>
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
>>
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)
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:
changes
> brought in by the merge/rebase. The pull request contains ten additional
> commits since the last revision:
>
> - Update after comments
> - Merge branch 'master' into ms-reinterpret2
> - Update
> src/java.base/share/classes/jdk/internal/foreign/HeapMemorySeg
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
>>
On Mon, 15 Apr 2024 07:50:24 GMT, Per Minborg wrote:
> This PR proposes to add a new method `MemorySegment::maxByteAlignment` that
> returns the maximum byte alignment of a segment (both heap and native
> segments).
>
> Clients can then use this method to determine if a segment is properly
>
On Wed, 10 Apr 2024 15:38:22 GMT, Jorn Vernee wrote:
> Please review this simple cleanup which removes the
> `AbstractLinker::linkerByteOrder` method. It was only used in
> `AixPPC64Linker`, where we know it will always return `ByteOrder.BIG_ENDIAN`
> so we can just repl
n-test-jdk_foreign`.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
update copyright years
-
Changes:
- all: https://git.openjdk.org/jdk/pull/18726/files
- new: https://git.openjdk.org/jdk/pull/18726/files/12ccb842.
Please review this simple cleanup which removes the
`AbstractLinker::linkerByteOrder` method. It was only used in `AixPPC64Linker`,
where we know it will always return `ByteOrder.BIG_ENDIAN` so we can just
replace the call with that.
Testing: Local run of `run-test-jdk_foreign`.
-
On Wed, 10 Apr 2024 12:49:11 GMT, Per Minborg wrote:
> This PR proposes to add two overloads `MemorySegment::reinterpretate` to
> allow aligned reinterpretation.
src/java.base/share/classes/jdk/internal/foreign/SegmentFactories.java line 72:
> 70:
On Mon, 18 Mar 2024 17:43:45 GMT, Suchismith Roy wrote:
>> Allow support for both .a and .so files in AIX.
>> If .so file is not found, allow fallback to .a extension.
>> JBS Issue: [JDK-8319516](https://bugs.openjdk.org/browse/JDK-8319516)
>
> Suchismith Roy has updated the pull request
On Wed, 13 Mar 2024 11:28:27 GMT, Jorn Vernee wrote:
> Update the code gen code in CallGeneratorHelper to reflect the latest state
> of the libTest(Downcall/Upcall)(Stack).c and shared.h files.
>
> - The previous code wanted users to pipe stdout into a file. But, since we
&g
On Wed, 20 Mar 2024 17:49:51 GMT, Maurizio Cimadamore
wrote:
> No changes in libTestDowncallStack.c (not even minor ones) ?
No, there was a 'missing' space between the prefix parameters and the actual
parameters of the stack variants, and between the arguments passed when that
callback was
files, but those files
> only contain either white space changes (some missing spaces after `,`), and
> copyright header updates.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Delete extra space
Co-authored-by: Andrey Turban
Update the code gen code in CallGeneratorHelper to reflect the latest state of
the libTest(Downcall/Upcall)(Stack).c and shared.h files.
- The previous code wanted users to pipe stdout into a file. But, since we have
5 files that need to be created, and the names of those files is important
On Tue, 12 Mar 2024 13:51:28 GMT, Magnus Ihse Bursie wrote:
>> test/jdk/java/foreign/CallGeneratorHelper.java line 216:
>>
>>> 214: if (header) {
>>> 215: System.out.println(
>>> 216: "#include \"export.h\"\n"
>>
>> We don't generate these header files any
On Wed, 6 Mar 2024 13: 43: 00 GMT, Magnus Ihse Bursie wrote: >> Currently, our symbol visibility handling for tests are sloppy; we only handle it properly on Windows. We need to bring it up to the same levels as
ZjQcmQRYFpfptBannerStart
This Message Is From an
On Mon, 26 Feb 2024 13:24:11 GMT, Jorn Vernee wrote:
> This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8,
> regardless of the underlying platform. This means that atomic access modes
> work on memory segments wrapping `long[]` or `double[]`, as they already d
On Mon, 26 Feb 2024 19:13:41 GMT, Jorn Vernee wrote:
>> That doesn't seem to be the right PR link?
>
> Found the right one:
> https://github.com/openjdk/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb
Switched back to using the old generator (and removed the newer one):
htt
On Mon, 26 Feb 2024 19:10:39 GMT, Jorn Vernee wrote:
>> test/jdk/java/foreign/TestLayouts.java line 164:
>>
>>> 162: );
>>> 163: assertEquals(struct.byteSize(), 1 + 1 + 2 + 4 + 8);
>>> 164: assertEquals(struct.byteAlignment(),
ing a stack overflow when running
> test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've
> lowered the recursion to 50 (which is still more than enough I think).
>
> Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86
> Linux (uses fa
On Mon, 26 Feb 2024 16:21:38 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review comments
>
> test/jdk/java/foreign/TestLayouts.java line 164
On Mon, 26 Feb 2024 15:10:55 GMT, Maurizio Cimadamore
wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> review comments
>
> src/java.base/share/classes/java/lang/foreign/MemorySe
ing a stack overflow when running
> test/jdk/java/foreign/stackwalk/TestReentrantUpcalls.java on x86, so I've
> lowered the recursion to 50 (which is still more than enough I think).
>
> Testing: `jdk_foreign` on x64 Windows, x64 Windows + fallback linker, and x86
> Linux (uses fa
This patch changes the alignment for `JAVA_LONG` and `JAVA_DOUBLE` to 8,
regardless of the underlying platform. This means that atomic access modes work
on memory segments wrapping `long[]` or `double[]`, as they already do when
using `MethodHandless::arrayAccessVarHandle`.
After discussion,
On Mon, 19 Feb 2024 08:19:58 GMT, Per Minborg wrote:
> This PR proposes to add an offset parameter for a `VarHandle` invocation in
> the Javadoc snippet for `Linker.Option.captureCallState()`. The offset
> parameter was added in 22 but it was forgotten to add it in said Javadoc.
Marked as
On Fri, 16 Feb 2024 15:54:27 GMT, Daniel D. Daugherty
wrote:
> A trivial fix to ProblemList jcstress tests that are failing due to
> JDK-8325984.
Thanks!
-
Marked as reviewed by jvernee (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/17890#pullrequestreview-1885494458
On Wed, 15 Nov 2023 22:46:03 GMT, Jorn Vernee wrote:
> See the JBS issue for an extended problem description.
>
> This patch changes the specification and implementation of
> `MethodHandles::byteArrayViewVarHandle`,
> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffe
* If the native platform does not guarantee stable alignment
> offset
> * values for the given unit size when managing the memory regions
> * of buffers of the same kind as this buffer (direct or
> * non-direct). For example, i
On Thu, 1 Feb 2024 20:10:29 GMT, Jorn Vernee wrote:
>> See the JBS issue for an extended problem description.
>>
>> This patch changes the specification and implementation of
>> `MethodHandles::byteArrayViewVarHandle`,
>> `MethodHandles::byteBufferViewVarHand
On Thu, 11 Jan 2024 16:21:38 GMT, Peter Levart wrote:
>> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It
>> returns `-1` (meaning that regions are equal) when passing the same instance
>> of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless
On Thu, 1 Feb 2024 21:10:48 GMT, Joe Darcy wrote:
> The restricted javac warning is disabled for java.base, but could be enabled
> by suppressing the warning in a handful of files.
This looks good to me. It will be easier to find where we are doing restricted
operations like this.
* If the native platform does not guarantee stable alignment
> offset
> * values for the given unit size when managing the memory regions
> * of buffers of the same kind as this buffer (direct or
> * non-direct). For example, i
On Tue, 30 Jan 2024 16:58:35 GMT, Per Minborg wrote:
>> This PR proposes to add an improved Improve
>> `LayoutPath.PathElement::toString` method simplifying debugging.
>>
>> Opinions and suggestions for `static PathElement sequenceElement(long start,
>> long step)` are welcome.
>
> Per
On Fri, 26 Jan 2024 09:12:53 GMT, Alan Bateman wrote:
> The target class is transformed in such a way to call the auxiliary class,
> which necessitates the the aux-class to be in the same classloader as the
> target class. But because the aux-class is defined while the target class is
> still
On Tue, 23 Jan 2024 14:43:24 GMT, Chen Liang wrote:
> Also curious, is there any documentation (like JVMS) that allows JVMs to make
> no offset into byte arrays aligned for larger access? Would be helpful if we
> can have a reference here.
There is simply no guarantee in the JVMS that array
On Tue, 23 Jan 2024 14:30:08 GMT, Chen Liang wrote:
>> Good idea. Thanks
>
> Should we make these unaligned access modes throw ISE like before, when the
> given index is unaligned?
You mean `get` and `set`? They should never throw, as unaligned access is fine.
For other access modes, we can
On Mon, 15 Jan 2024 16:01:32 GMT, Per Minborg wrote:
>> This PR proposes to add an improved Improve
>> `LayoutPath.PathElement::toString` method simplifying debugging.
>>
>> Opinions and suggestions for `static PathElement sequenceElement(long start,
>> long step)` are welcome.
>
> Per
On Fri, 12 Jan 2024 13:06:39 GMT, Per Minborg wrote:
>> This PR proposes to add a clarification that an `Arena` always returns
>> zeroed-out segments for `Arena::allocate` methods.
>>
>> Note that other overloaded methods refer to the abstract `Arena::allocate`
>> method via implementation
On Thu, 11 Jan 2024 07:59:37 GMT, Per Minborg wrote:
>> This PR proposes to add a clarification that an `Arena` always returns
>> zeroed-out segments for `Arena::allocate` methods.
>>
>> Note that other overloaded methods refer to the abstract `Arena::allocate`
>> method via implementation
On Thu, 11 Jan 2024 13:30:44 GMT, Peter Levart wrote:
>> I belive there is a bug in `AbstractMemorySegmentImpl#mismatch` method. It
>> returns `-1` (meaning that regions are equal) when passing the same instance
>> of MemorySegment as both `srcSegment` and `dstSegment` parameters regardless
On Wed, 10 Jan 2024 13:18:17 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [d2d58dd6](https://github.com/openjdk/jdk/commit/d2d58dd6a8ec366a4bc3eb12a253b252de24557e)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
1 - 100 of 802 matches
Mail list logo
