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 ne
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 Minborg
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 not
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 not
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.
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.
The commit being backported was authored by Jorn Vernee on 10 Jan 2024 and was
On Wed, 10 Jan 2024 15:10:58 GMT, Claes Redestad wrote:
> JMH microbenchmarks may have dependencies on artifacts in the test image
> outside of the benchmarks.jar. This includes native libraries (built into
> `$TEST_IMAGE/micro/native`) and may soon include other test libraries like
> wb.jar (
On Wed, 10 Jan 2024 14:21:15 GMT, Maurizio Cimadamore
wrote:
> (how does a client know if what they get back is zeroed?)
It seems similar to e.g. a HashMap vs. LinkedHashMap with regards to ordering.
The creator of the Arena would decide the zeroing strategy.
-
PR Review Comment:
On Mon, 8 Jan 2024 16:16:50 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 notes.
s
On Tue, 9 Jan 2024 14:18:37 GMT, Jorn Vernee wrote:
> The issue with this test, and the test of JDK-8322324, seems to be that the
> forked processes write to stderr/stdout, without this output being read
> before the process terminates. The buffer might fill up if the output is not
ng a stall. Incidentally, `startProcess` also has
> built-in timeout handling which we can use.
>
> Testing:
> - 500 runs of both java/foreign/TestStubAllocFailure.java and
> java/foreign/critical/TestCriticalUpcall on various Windows x64 hosts (100
> iterations was enough
The issue with this test, and the test of JDK-8322324, seems to be that the
forked processes write to stderr/stdout, without this output being read before
the process terminates. The buffer might fill up if the output is not being
read, which means that the process will stall when writing (see s
On Fri, 15 Dec 2023 05:15:17 GMT, David Holmes wrote:
>> Any non-zero exit value is acceptable. The intent here is to check that the
>> process didn't complete normally.
>
> A non-zero non-crashing value. Just wondering what that actually would be?
For instance, when we exit due to an uncaught
On Wed, 13 Dec 2023 17:38:27 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [7ece9e90](https://github.com/openjdk/jdk/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
On Wed, 13 Dec 2023 05:19:25 GMT, Stuart Marks wrote:
>> The `-D` command-line option is not a part of the Java SE specification but
>> an allowed behavior, so it may not be a normative description here.
>
> Right, I suggested putting that in parentheses. Historically we haven't been
> very for
Hi all,
This pull request contains a backport of commit
[7ece9e90](https://github.com/openjdk/jdk/commit/7ece9e90c0198f92cdf8d620e346c4a9832724cd)
from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
The commit being backported was authored by Jorn Vernee on 13 Dec 2023 and was
On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee wrote:
> Improve the test by being more lenient to related code cache exhaustion
> errors. The important thing is that we don't terminate with a fatal error,
> which the new code now checks for explicitly. The check for that is based
On Wed, 13 Dec 2023 07:08:53 GMT, David Holmes wrote:
>> Improve the test by being more lenient to related code cache exhaustion
>> errors. The important thing is that we don't terminate with a fatal error,
>> which the new code now checks for explicitly. The check for that is based on
>> what
On Tue, 12 Dec 2023 12:09:50 GMT, Maurizio Cimadamore
wrote:
>> Improve the test by being more lenient to related code cache exhaustion
>> errors. The important thing is that we don't terminate with a fatal error,
>> which the new code now checks for explicitly. The check for that is based on
On Mon, 11 Dec 2023 13:01:25 GMT, Jorn Vernee wrote:
> Improve the test by being more lenient to related code cache exhaustion
> errors. The important thing is that we don't terminate with a fatal error,
> which the new code now checks for explicitly. The check for that is based
Improve the test by being more lenient to related code cache exhaustion errors.
The important thing is that we don't terminate with a fatal error, which the
new code now checks for explicitly. The check for that is based on what is done
by `./test/hotspot/jtreg/runtime/ErrorHandling/HsErrFileUti
On Mon, 4 Dec 2023 21:25:41 GMT, Martin Doerr wrote:
> I'd like to clean this up: Use the canonical layouts which are available in
> JDK22. Use try-with-resources for `Arena.ofConfined()`.
Marked as reviewed by jvernee (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/1695
On Mon, 4 Dec 2023 09:10:07 GMT, Per Minborg wrote:
>> This PR proposes to reject paths provided to the
>> `SymbolLookup.libraryLookup(Path path, Arena arena)` method if a path is not
>> in the default file system.
>
> Per Minborg has updated the pull request incrementally with one additional
On Mon, 4 Dec 2023 14:49:39 GMT, Jorn Vernee wrote:
>> Chen Liang has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains two commits:
>>
>> - Merge branch 'master' of https://github.com/openjdk/jdk
On Mon, 6 Nov 2023 08:19:19 GMT, Chen Liang wrote:
>> VarHandle implementations have many static fields and methods that can be
>> pulled to the common superclass to avoid repeated initialization and code
>> duplication.
>>
>> In addition, the Unsafe-based Buffer field access are replaced by u
On Thu, 30 Nov 2023 20:59:01 GMT, Jorn Vernee wrote:
> Need to use `jlong_to_ptr` instead of raw cast.
>
> I've also fixed another latent issue in `CLayouts` where we were initializing
> `C_LONG_LONG` with the `long` layout. This was resulting in a class cast
> except
Need to use `jlong_to_ptr` instead of raw cast.
I've also fixed another latent issue in `CLayouts` where we were initializing
`C_LONG_LONG` with the `long` layout. This was resulting in a class cast
exception when running the XorTest benchmark. The size of `long` on Linux x86
32-bits is 4 bytes
On Mon, 23 Oct 2023 13:58:27 GMT, Jorn Vernee wrote:
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
This pull request has
On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote:
> This test is problematic on Zero due to
> https://bugs.openjdk.org/browse/JDK-8321064
>
> Disable it for now on that platform, until a Zero maintainer has a chance to
> look into it.
>
> Testing: running TestHandshak
On Thu, 30 Nov 2023 15:48:11 GMT, Jorn Vernee wrote:
> This test is problematic on Zero due to
> https://bugs.openjdk.org/browse/JDK-8321064
>
> Disable it for now on that platform, until a Zero maintainer has a chance to
> look into it.
>
> Testing: running TestHandshak
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Jorn Vernee has updated the pull request with a new target base due to a me
On Thu, 30 Nov 2023 16:14:37 GMT, Aleksey Shipilev wrote:
> Hold on, can we figure out if Zero can actually be fixed before we go and
> disable the test? I think we only disable the tests like this if there is an
> intrinsic reason why the test does not apply to a platform.
I would problem lis
This test is problematic on Zero due to
https://bugs.openjdk.org/browse/JDK-8321064
Disable it for now on that platform, until a Zero maintainer has a chance to
look into it.
Testing: running TestHandshake on zero to see that it is skipped.
-
Commit messages:
- disable TestHandsh
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`, `ByteBuffer::ali
On Thu, 23 Nov 2023 16:34:23 GMT, Erik Österlund wrote:
>> The current logic for closing memory in panama today is susceptible to live
>> lock if we have a closing thread that wants to close the memory in a loop
>> that keeps failing, and a bunch of accessing threads that want to perform
>> ac
On Thu, 23 Nov 2023 11:14:29 GMT, Erik Österlund wrote:
> The current logic for closing memory in panama today is susceptible to live
> lock if we have a closing thread that wants to close the memory in a loop
> that keeps failing, and a bunch of accessing threads that want to perform
> access
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Tue, 21 Nov 2023 19:30:30 GMT, suchismith1993 wrote:
>> The math library in AIX specifically, is a static archive. Doing a -lm wont
>> suffice, because when the symbols are looked up using dlsym or accessing
>> native code through Java, it will lead to failures.
>> Hence we had to come up wi
On Wed, 22 Nov 2023 02:06:29 GMT, Hao Sun wrote:
> The fix is trivial. We should include the standard C header `stdlib.h` [1],
> rather than non-standard one `malloc.h`.
>
> [1] https://en.cppreference.com/w/c/memory/malloc
Thanks.
-
Marked as reviewed by jvernee (Reviewer).
PR
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> The math library in AIX specifically, is a static archive. Doing a -lm wont
> suffice, because when the symbols are looked up using dlsym or accessing
> native code through Java, it will lead to failures.
> Hence we had to come up with a
On Fri, 17 Nov 2023 13:02:22 GMT, Martin Doerr wrote:
> My understanding is that a lot of symbols can be found out of the box because
> they are in dynamically linked libraries. Only some libraries are special on
> AIX which don't support dynamic linking and we need this workaround for them.
T
On Thu, 16 Nov 2023 19:56:51 GMT, Phil Race wrote:
> > > > > > layoutCnt=16000 total=193ms <<< app fully displayed
> > > > > > vs
> > > > > > layoutCnt=16000 total=453ms <<< app fully displayed
> > > > >
> > > > >
> > > > > It looks strange that 16000 calls are not enough to warmup, and the
>
On Thu, 16 Nov 2023 01:54:29 GMT, Sergey Bylokhov wrote:
> > > > So we have somewhere around a fixed 125ms startup cost for the FFM case
> > > > - as measured on my Mac,
> > > > but only 35-40ms of that is attributable to the specific needs of
> > > > layout.
> > >
> > >
> > > That looks unfo
On Thu, 16 Nov 2023 06:29:20 GMT, Alan Bateman wrote:
>> See the JBS issue for an extended problem description.
>>
>> This patch changes the specification and implementation of
>> `MethodHandles::byteArrayViewVarHandle`,
>> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`,
See the JBS issue for an extended problem description.
This patch changes the specification and implementation of
`MethodHandles::byteArrayViewVarHandle`,
`MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, and
`ByteBuffer::alignmentOffset` to weaken the guarantees they make a
On Thu, 16 Nov 2023 17:31:46 GMT, Paul Sandoz wrote:
>> See the JBS issue for an extended problem description.
>>
>> This patch changes the specification and implementation of
>> `MethodHandles::byteArrayViewVarHandle`,
>> `MethodHandles::byteBufferViewVarHandle`, `ByteBuffer::alignedSlice`, a
On Thu, 16 Nov 2023 18:52:03 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4610:
>>
>>> 4608: * {@link Double#doubleToRawLongBits}, respectively).
>>> 4609: *
>>> 4610: * Access to heap byte buffers is always unaligned.
>
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`, `ByteBuffer::ali
On Thu, 16 Nov 2023 18:38:54 GMT, Maurizio Cimadamore
wrote:
>> This simplePR tweaks the factory which wraps custom cleanup actions passed
>> to `MemorySegment::reinterpret`, so that any exception thrown by the custom
>> cleanup is swallowed when the arena is closed.
>>
>> This aligns the beh
On Thu, 16 Nov 2023 18:24:44 GMT, Maurizio Cimadamore
wrote:
>> This simplePR tweaks the factory which wraps custom cleanup actions passed
>> to `MemorySegment::reinterpret`, so that any exception thrown by the custom
>> cleanup is swallowed when the arena is closed.
>>
>> This aligns the beh
On Wed, 15 Nov 2023 02:39:56 GMT, Mandy Chung wrote:
>> This PR includes test fixes for the following issues:
>>
>> 8319567: Update java/lang/invoke tests to support vm flags
>> 8319568: Update java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
>> to accept vm flags
>> 8319672: Several
On Tue, 14 Nov 2023 22:45:56 GMT, Mandy Chung wrote:
> This PR includes test fixes for the following issues:
>
> 8319567: Update java/lang/invoke tests to support vm flags
> 8319568: Update java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> to accept vm flags
> 8319672: Several class
On Tue, 14 Nov 2023 22:45:56 GMT, Mandy Chung wrote:
> This PR includes test fixes for the following issues:
>
> 8319567: Update java/lang/invoke tests to support vm flags
> 8319568: Update java/lang/reflect/exeCallerAccessTest/CallerAccessTest.java
> to accept vm flags
> 8319672: Several class
On Mon, 13 Nov 2023 12:51:36 GMT, Jorn Vernee wrote:
>> Add the ability to pass heap segments to native code. This requires using
>> `Linker.Option.critical(true)` as a linker option. It has the same
>> limitations as normal critical calls, namely: upcalls into Java are no
On Tue, 14 Nov 2023 23:04:16 GMT, Sergey Bylokhov wrote:
>> Jorn Vernee has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 52 commits:
>>
>> - Merge branch 'master' into AllowHeapNoLock
>>
On Mon, 16 Oct 2023 10:19:17 GMT, Jorn Vernee wrote:
> Add the ability to pass heap segments to native code. This requires using
> `Linker.Option.critical(true)` as a linker option. It has the same
> limitations as normal critical calls, namely: upcalls into Java are not
> allo
On Mon, 13 Nov 2023 16:09:10 GMT, Maurizio Cimadamore
wrote:
>> This simplePR tweaks the factory which wraps custom cleanup actions passed
>> to `MemorySegment::reinterpret`, so that any exception thrown by the custom
>> cleanup is swallowed when the arena is closed.
>>
>> This aligns the beh
On Thu, 9 Nov 2023 15:39:54 GMT, Jorn Vernee wrote:
>> src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp line 182:
>>
>>> 180: ArgumentShuffle arg_shuffle(filtered_java_regs, out_regs,
>>> shuffle_reg);
>>> 181:
>>> 182: #ifndef PRODUCT
>
t; - Fallback linker is also supported using JNI's
> `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring
> segments in interpreted mode.
>
> Numbers for the included benchmark on my machi
On Fri, 10 Nov 2023 16:34:11 GMT, Maurizio Cimadamore
wrote:
> This simplePR tweaks the factory which wraps custom cleanup actions passed to
> `MemorySegment::reinterpret`, so that any exception thrown by the custom
> cleanup is swallowed when the arena is closed.
>
> This aligns the behavior
On Fri, 10 Nov 2023 07:56:46 GMT, suchismith1993 wrote:
> > That said, I think we should limit the exported symbols to only those found
> > in the standard C library header files:
> > https://en.cppreference.com/w/c/header
>
> Currently the symbols are restricted to some parts of libc and the
On Mon, 13 Nov 2023 02:32:48 GMT, David Holmes wrote:
> I cannot decide if this is an AIX issue for not using dynamic libraries; a
> FFI issue for assuming dynamic libraries; or a test issue. Won't this be a
> general problem for any function you try to access via FFI that is statically
> link
t; - Fallback linker is also supported using JNI's
> `GetPrimitiveArrayCritical`/`ReleasePrimitiveArrayCritical`
>
> Aside: fixed existing issue with `DowncallLinker` not properly acquiring
> segments in interpreted mode.
>
> Numbers for the included benchmark on my machi
On Thu, 9 Nov 2023 00:27:46 GMT, Vladimir Ivanov wrote:
> Even though it's straightforward to support on-heap accesses during critical
> function calls, object pinning would support that for non-critical function
> calls as well, but proposed API doesn't cover it and new API will be
> required
On Wed, 8 Nov 2023 19:52:00 GMT, Vladimir Ivanov wrote:
>> Jorn Vernee has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - a -> an
>> - add note to downcallHandle about passing heap segments by-refe
On Mon, 30 Oct 2023 10:54:48 GMT, suchismith1993 wrote:
> 1. Adding required compiler flags.
> 2. Adding required symbols.
>
> JBS-ISSUE : [JDK-8317799](https://bugs.openjdk.org/browse/JDK-8317799)
For some context: `java.lang.foreign.Linker.nativeLinker().defaultLookup()`
returns a `SymbolLoo
On Fri, 3 Nov 2023 00:10:48 GMT, Jorn Vernee wrote:
> - Add linker note about packed structs.
> - Relax language a bit to avoid implying that only listed layouts are
> supported.
This pull request has now been integrated.
Changeset: cdf33735
Author:Jorn Vernee
URL:
On Mon, 6 Nov 2023 10:10:41 GMT, Per Minborg wrote:
>> This PR proposes to reformat all the JavaDocs for the FFM API. This would
>> bring the FFM API docs more in line with the existing Java documentation
>> (see below). Occasional drive-by fixes are also included in this PR (such
>> as spell
On Mon, 6 Nov 2023 10:13:14 GMT, Per Minborg wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add 'strict'
>>
>> Co-authored-by: Maurizio Cimadamore
>> <
> - Add linker note about packed structs.
> - Relax language a bit to avoid implying that only listed layouts are
> supported.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
Add 'strict'
Co-authored-by:
On Fri, 3 Nov 2023 16:17:32 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/foreign/Linker.java line 247:
>>
>>> 245: *
>>> 246: *
>>> 247: * Linker implementations may optionally support additional layouts,
>>> such as &#x
> - Add linker note about packed structs.
> - Relax language a bit to avoid implying that only listed layouts are
> supported.
Jorn Vernee has updated the pull request incrementally with one additional
commit since the last revision:
add examples of packed structs
-
On Fri, 3 Nov 2023 14:48:31 GMT, Maurizio Cimadamore
wrote:
>> - Add linker note about packed structs.
>> - Relax language a bit to avoid implying that only listed layouts are
>> supported.
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 247:
>
>> 245: *
>> 246: *
>> 247:
- Add linker note about packed structs.
- Relax language a bit to avoid implying that only listed layouts are supported.
-
Commit messages:
- simplify language
- - Add linker note about packed structs.
Changes: https://git.openjdk.org/jdk/pull/16485/files
Webrev: https://webrevs.o
On Thu, 2 Nov 2023 23:19:24 GMT, Jorn Vernee wrote:
>> Explicitly handle UpcallStub allocation failures by terminating. We
>> currently might try to use the returned `nullptr` which would fail sooner or
>> later. This patch just makes the termination explicit.
>
> Jor
On Thu, 2 Nov 2023 14:46:49 GMT, Per Minborg wrote:
> This PR proposes to harmonize the @throws tags in the javadocs for the FFM
> API.
>
> The @throws tags are using a bit different principles with respect to
> formatting and ending with a period or not.
>
> Looking at some prominent Java cl
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Jorn Vernee has updated the pull request incrementally with one additional
com
On Wed, 1 Nov 2023 18:43:24 GMT, Martin Doerr wrote:
>> Martin Doerr has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Improve handling of layouts in NativeType.java
>> - Check byte order of 4-byte aligned double.
>
> Thanks for testing
On Wed, 1 Nov 2023 14:10:10 GMT, Maurizio Cimadamore
wrote:
> This PR fixes an inexact var handle call that sneaked in as part of
> https://git.openjdk.org/jdk/pull/16224.
>
> As some default methods were moved from `MemorySegment` to
> `AbstractMemorySegmentImpl`, the type of `this` has chan
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Jorn Vernee has updated the pull request incrementally with one additional
com
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Jorn Vernee has updated the pull request incrementally with three additional
On Thu, 26 Oct 2023 18:11:01 GMT, Jorn Vernee wrote:
>> Explicitly handle UpcallStub allocation failures by terminating. We
>> currently might try to use the returned `nullptr` which would fail sooner or
>> later. This patch just makes the termination explicit.
>
> Jor
On Fri, 27 Oct 2023 08:52:42 GMT, Maurizio Cimadamore
wrote:
>> OOME is pretty much understood to be possible anywhere, given it is a
>> VirtualMachineError. We often do not document it explicitly. The risk with
>> documenting it is that it gives the impression that other methods, which
>> do
On Fri, 27 Oct 2023 03:49:17 GMT, Yasumasa Suenaga wrote:
>> src/hotspot/cpu/x86/downcallLinker_x86_64.cpp line 110:
>>
>>> 108: __ mov(rsp, r12); // restore sp
>>> 109: __ reinit_heapbase();
>>> 110: }
>>
>> This is a minor cleanup to share this code for the three use sites below.
>
> Ques
On Fri, 27 Oct 2023 05:26:47 GMT, David Holmes wrote:
> @JornVernee please don't forget that all non-trivial (as defined by the dev
> guide) hotspot changes require at least 2 reviews and a 24 hour wait before
> integration. Thanks.
Right, sorry. I think I confused this PR with
https://github
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Jorn Vernee has updated the pull request incrementally with one additional
com
On Thu, 26 Oct 2023 18:07:24 GMT, Jorn Vernee wrote:
>> Explicitly handle UpcallStub allocation failures by terminating. We
>> currently might try to use the returned `nullptr` which would fail sooner or
>> later. This patch just makes the termination explicit.
>
> Jor
On Wed, 25 Oct 2023 10:10:57 GMT, Jorn Vernee wrote:
>> Explicitly handle UpcallStub allocation failures by terminating. We
>> currently might try to use the returned `nullptr` which would fail sooner or
>> later. This patch just makes the termination explicit.
>
> Jor
On Tue, 24 Oct 2023 17:01:35 GMT, Jorn Vernee wrote:
> The result of `FindClass` is a local JNI handle (in
> `find_class_from_class_loader`, called from `jni_FindClass` [1]). As such, we
> need to wrap the return value of `FindClass` in a global reference when
> stori
; at
> jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@22-internal/DirectMethodHandleAccessor.java:154)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@22-internal/DirectMethodHandleAccessor.java:103)
> at
> java.
On Thu, 26 Oct 2023 12:17:22 GMT, David Holmes wrote:
> Is stub allocation the same as other VM C heap exhaustion cases?
I think it depends on the particular case. e.g. `Unsafe::allocateMemory` can
also throw OOME.
I think an allocation failure in the particular case of the FFM Linker
allocat
On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee wrote:
>> Add the ability to pass heap segments to native code. This requires using
>> `Linker.Option.critical(true)` as a linker option. It has the same
>> limitations as normal critical calls, namely: upcalls into Java are no
On Tue, 24 Oct 2023 15:09:57 GMT, Jorn Vernee wrote:
>> Add the ability to pass heap segments to native code. This requires using
>> `Linker.Option.critical(true)` as a linker option. It has the same
>> limitations as normal critical calls, namely: upcalls into Java are no
On Wed, 25 Oct 2023 09:32:42 GMT, Aleksey Shipilev wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> explicitly propagate fallback library init failures
>
> src/java.base/
; at
> jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(java.base@22-internal/DirectMethodHandleAccessor.java:154)
> at
> jdk.internal.reflect.DirectMethodHandleAccessor.invoke(java.base@22-internal/DirectMethodHandleAccessor.java:103)
> at
> java.
> Explicitly handle UpcallStub allocation failures by terminating. We currently
> might try to use the returned `nullptr` which would fail sooner or later.
> This patch just makes the termination explicit.
Jorn Vernee has updated the pull request incrementally with one additional
com
On Wed, 25 Oct 2023 10:01:29 GMT, Aleksey Shipilev wrote:
>> Not sure what you're saying here. As far as I understand the intent of this
>> code is to check whether the handle is of a certain type, and if it's not
>> recognized, return `JNIInvalidRefType`. So, I'm not sure there should be any
On Wed, 25 Oct 2023 09:56:45 GMT, Aleksey Shipilev wrote:
> this PR does not change the failure mode substantially, right?
That's right.
-
PR Comment: https://git.openjdk.org/jdk/pull/16311#issuecomment-1778922469
On Wed, 25 Oct 2023 09:47:13 GMT, Aleksey Shipilev wrote:
> > But it sounds like you're saying that plain user code should never result
> > in a VM error (if we can help it).
>
> Yes, exactly. Granted, there are resource exhaustion situations where the
> overall progress could be sluggish (e.g
201 - 300 of 916 matches
Mail list logo
