On Thu, 1 Jun 2023 21:04:27 GMT, Maurizio Cimadamore
wrote:
>> src/java.base/share/classes/java/lang/foreign/Linker.java line 473:
>>
>>> 471:
>>> 472: /**
>>> 473: * Creates a method handle which is used to call a foreign
>>> functi
On Thu, 1 Jun 2023 18:12:28 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java
On Thu, 1 Jun 2023 19:25:38 GMT, Jorn Vernee wrote:
>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 645:
>>
>>> 643: * is 1. As such, regardless of its size, in the absence of an
>>> {@linkplain #withByteAlignment(long) explicit}
>>> 644: * alignment
On Thu, 1 Jun 2023 19:36:48 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix wrong link in layout well-formedness doc
>
> src/java.base/share/classes/java/l
On Thu, 1 Jun 2023 13:16:44 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Fix wrong link in layout well-formedness doc
>
> src/java.base/s
On Thu, 1 Jun 2023 15:16:42 GMT, Jorn Vernee wrote:
>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and
>> `float` is promoted to `double`, when being passed as variadic argument (see
>> e.g.
>>
On Wed, 31 May 2023 22:44:52 GMT, Jorn Vernee wrote:
>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and
>> `float` is promoted to `double`, when being passed as variadic argument (see
>> e.g.
>>
On Wed, 31 May 2023 23:35:08 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/Linker.java li
On Wed, 31 May 2023 22:44:52 GMT, Jorn Vernee wrote:
>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and
>> `float` is promoted to `double`, when being passed as variadic argument (see
>> e.g.
>>
On Tue, 30 May 2023 17:25:35 GMT, Jorn Vernee wrote:
> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and
> `float` is promoted to `double`, when being passed as variadic argument (see
> e.g.
>
On Wed, 31 May 2023 15:39:31 GMT, Maurizio Cimadamore
wrote:
>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and
>> `float` is promoted to `double`, when being passed as variadic argument (see
>> e.g.
>> https://en.cppreference.com
On Tue, 30 May 2023 12:17:00 GMT, Jorn Vernee wrote:
> The issue is that the fallback linker uses `copyFrom` when copying a by-value
> struct argument to an internal buffer, without first adjusting the size of
> the argument segment. This means that if the argument segment is 'too large'
>
On Mon, 29 May 2023 10:39:19 GMT, Maurizio Cimadamore
wrote:
> There's an obvious bug in `AbstractMemorySegmentImpl::reinterpret(long,
> Arena, Consumer)`: this method does not pass the consumer down to the
> internal implementation method (it just passes `null`). As a result, the
epting a layout path can simply refer to it (this definition is tricky to
> give inline in the javadoc of the various path-accepting methods, as it
> depends on many factors).
>
> Another biggie change was in `MemorySegment` as now all dereference methods
> state precisely their spatia
There's an obvious bug in `AbstractMemorySegmentImpl::reinterpret(long, Arena,
Consumer)`: this method does not pass the consumer down to the internal
implementation method (it just passes `null`). As a result, the cleanup is not
registered.
-
Commit messages:
- Remove redundant
On Thu, 25 May 2023 15:31:43 GMT, Maurizio Cimadamore
wrote:
>> As the FFM API evolved over time, some parts of the javadoc went out of
>> sync. Now that most of the API is stable, it is a good time to look again at
>> the javadoc as a whole, and bring some more consistency.
epting a layout path can simply refer to it (this definition is tricky to
> give inline in the javadoc of the various path-accepting methods, as it
> depends on many factors).
>
> Another biggie change was in `MemorySegment` as now all dereference methods
> state precisely their spatia
On Wed, 24 May 2023 09:36:34 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
On Wed, 17 May 2023 17:15:06 GMT, Maurizio Cimadamore
wrote:
> This patch adds an instance method on `Linker`, namely
> `Linker::canonicalLayouts` which returns all the layouts known by the linker
> as implementing some ABI type. For instance, if I call this on my machine
> (Linu
epting a layout path can simply refer to it (this definition is tricky to
> give inline in the javadoc of the various path-accepting methods, as it
> depends on many factors).
>
> Another biggie change was in `MemorySegment` as now all dereference methods
> state precisely their spatia
On Wed, 24 May 2023 15:22:15 GMT, Maurizio Cimadamore
wrote:
> There is a difference in behavior between `System::loadLibrary` and
> `SymbolLookup::libraryLookup(String)`. While the former catches library names
> containing NULL chars (because, internally it uses Path/File log
es not contain `\0`
> and, if so, throw `IllegalArgumentException` (which is already covered by
> current spec;
> * the name of a symbol passed to `SymbolLookup::find` does not contain `\0`
> and, if so, return empty optional. This required changes on all the lookups
> we im
On Wed, 24 May 2023 16:30:25 GMT, Paul Sandoz wrote:
> Do you also need to test on `SymbolLookup` returned from
> `Linker::defaultLookup`?
Yeah - some test would be better.
-
PR Comment: https://git.openjdk.org/jdk/pull/14126#issuecomment-1561568364
There is a difference in behavior between `System::loadLibrary` and
`SymbolLookup::libraryLookup(String)`. While the former catches library names
containing NULL chars (because, internally it uses Path/File logic, which
reject those), `SymbolLookup` does not. As a result, it is possible to load
On Wed, 24 May 2023 13:44:40 GMT, Martin Doerr wrote:
>> Do you prefer removing it?
>
> I think it's not important. I'll just integrate it to get the tests working
> again.
Yeah, let's integrate
-
PR Review Comment: https://git.openjdk.org/jdk/pull/14116#discussion_r1204172106
On Wed, 24 May 2023 09:16:46 GMT, Martin Doerr wrote:
> Please review this trivial adaptation for JDK-8308276.
Looks good - I apologize for having missed it.
test/jdk/java/foreign/TestHFA.java line 53:
> 51: final static SymbolLookup lookup = SymbolLookup.loaderLookup();
> 52:
> 53:
This can be useful to discover the ABI types supported by a linker
> implementation, as well as for, in the future, add support for more exotic
> (and platform-dependent) linker types, such as `long double` or `complex
> long`.
Maurizio Cimadamore has updated the pull request with a new target
On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
This can be useful to discover the ABI types supported by a linker
> implementation, as well as for, in the future, add support for more exotic
> (and platform-dependent) linker types, such as `long double` or `complex
> long`.
Maurizio Cimadamore has updated the pull request incremental
On Tue, 23 May 2023 20:32:10 GMT, Maurizio Cimadamore
wrote:
> Arguably C `unsigned short` could map to carriers Java `short` or Java
> `char`, but i am inclined to say the user should cast between Java `short` to
> `char` in such cases.
(Another advantage of this is that, shou
On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
As the FFM API evolved over time, some parts of the javadoc went out of sync.
Now that most of the API is stable, it is a good time to look again at the
javadoc as a whole, and bring some more consistency.
While most of the changes in this PR are stylistic, I'd like to call out few
things
On Tue, 23 May 2023 11:48:59 GMT, Maurizio Cimadamore
wrote:
> As the FFM API evolved over time, some parts of the javadoc went out of sync.
> Now that most of the API is stable, it is a good time to look again at the
> javadoc as a whole, and bring some more consistency.
>
On Fri, 19 May 2023 23:08:00 GMT, Paul Sandoz wrote:
>>> This look much better. Can we strengthen the specification of
>>> `canonicalLayouts` in accordance with the class specification
>>
>> We can't do more in that method javadoc, think, as that has to be general
>> enough for all linkers.
On Mon, 22 May 2023 15:21:37 GMT, Per Minborg wrote:
> This PR adds a test that shows the documented way of calling `printf` works.
I'm not sure I get this: StdLibTest already tests variadic calls, and there's a
brand new javadoc section about this topic:
On Mon, 22 May 2023 14:34:32 GMT, Per Minborg wrote:
> LGTM. Are there any additional types we might consider apart from the basic
> ones and `size_t`? Maybe one for an address pointing at `errno`?
I think there is a certain gravitational pull towards keeping the set of
guaranteed canonical
On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore
wrote:
> As explained in [1], memory layouts and memory segments describe sizes using
> different units. Memory layouts use bits, whereas memory segments use bytes.
> This is historical: memory layouts were designed after the Mi
On Fri, 12 May 2023 12:11:23 GMT, Maurizio Cimadamore
wrote:
> This patch adds a simpler method for composing symbol lookups. It is common
> for clients to chain multiple symbol lookups together, e.g. to find a symbol
> in multiple libraries.
>
> A new instance method, namel
ing the layout API directly.
>
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html
Maurizio Cimadamore has updated the pull request with a new target base due to
a merge or a rebase. The pull request now contains 11 commits:
- Merge branch 'master' into bits_to_byt
On 17/05/2023 02:33, John Hendrikx wrote:
SymbolLookup lookUp = name -> library1.find(name)
.or(() -> library2.find(name))
.or(() -> loader.find(name));
What you say is true - e.g. the fact that a lookup returns an optional
can be used to chain multiple lookups as you
This can be useful to discover the ABI types supported by a linker
> implementation, as well as for, in the future, add support for more exotic
> (and platform-dependent) linker types, such as `long double` or `complex
> long`.
Maurizio Cimadamore has updated the pull request incrementally
On Fri, 19 May 2023 22:43:56 GMT, Paul Sandoz wrote:
> This look much better. Can we strengthen the specification of
> `canonicalLayouts` in accordance with the class specification
We can't do more in that method javadoc, think, as that has to be general
enough for all linkers. I think the
On Fri, 19 May 2023 22:20:32 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with two
>> additional commits since the last revision:
>>
>> - Address review comments
>> - More javadoc tweaks
>
> src/java.
On Tue, 16 May 2023 11:18:09 GMT, Maurizio Cimadamore
wrote:
> The FFM API exposes layout constants for Java primitives. Among those there
> are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of
> these layouts is set the same as their size (e.g
On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
This can be useful to discover the ABI types supported by a linker
> implementation, as well as for, in the future, add support for more exotic
> (and platform-dependent) linker types, such as `long double` or `complex
> long`.
Maurizio Cimadamore has updated the pull request incrementally wi
On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
ed by heap segments, so that it is 4 for long[] and
> double[] on 32-bit platforms.
Maurizio Cimadamore has updated the pull request incrementally with one
additional commit since the last revision:
Fix tests for x86
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14007/files
ed by heap segments, so that it is 4 for long[] and
> double[] on 32-bit platforms.
Maurizio Cimadamore has updated the pull request incrementally with one
additional commit since the last revision:
Add simple sanity check
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14007
On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore
wrote:
>> This patch adds an instance method on `Linker`, namely
>> `Linker::canonicalLayouts` which returns all the layouts known by the linker
>> as implementing some ABI type. For instance, if I call this on my machine
On Thu, 18 May 2023 16:52:15 GMT, Paul Sandoz wrote:
> Here's the crux of what i am wondering about. Can we specify native linker
> support for a subset of the System V Application Binary Interface (e.g., LP64
> and ILP32 programming models for all non-optional scalar types, sequences of,
>
On Thu, 18 May 2023 09:28:14 GMT, Maurizio Cimadamore
wrote:
>> The FFM API exposes layout constants for Java primitives. Among those there
>> are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of
>> these layouts is set the same as their
ed by heap segments, so that it is 4 for long[] and
> double[] on 32-bit platforms.
Maurizio Cimadamore has updated the pull request incrementally with one
additional commit since the last revision:
Address review comments
Actually tweak alignment of ValueLayout.OfLong/ValueLayout.
ing the layout API directly.
>
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html
Maurizio Cimadamore has updated the pull request incrementally with one
additional commit since the last revision:
Address review comments
-
Changes:
- all: https://git
ing the layout API directly.
>
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html
Maurizio Cimadamore has updated the pull request incrementally with five
additional commits since the last revision:
- Update test/jdk/java/foreign/TestLayouts.java
Co-authored-b
On Wed, 17 May 2023 22:41:16 GMT, Paul Sandoz wrote:
> So maybe this comes down to the linker supporting a subset ABI's data types,
> and that subset might increase over time, but never decrease? In this respect
> could we present a table for each supported linker ABI listing the ABI type
>
On Wed, 17 May 2023 22:08:57 GMT, Paul Sandoz wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Tweak javadoc
>
> src/java.base/share/classes/java/lang/foreign/Linker.java l
This can be useful to discover the ABI types supported by a linker
> implementation, as well as for, in the future, add support for more exotic
> (and platform-dependent) linker types, such as `long double` or `complex
> long`.
Maurizio Cimadamore has updated the pull request incrementall
On 17/05/2023 18:52, Maurizio Cimadamore wrote:
I believe that would be an experiment worth doing (if you can!), and
report back if you find any compilation problems.
Ah - I missed this critical last line:
P.S.: To be honest: I tried to pass "--release 21" when compili
On Wed, 17 May 2023 17:15:06 GMT, Maurizio Cimadamore
wrote:
> This patch adds an instance method on `Linker`, namely
> `Linker::canonicalLayouts` which returns all the layouts known by the linker
> as implementing some ABI type. For instance, if I call this on my machine
> (Linu
This patch adds an instance method on `Linker`, namely
`Linker::canonicalLayouts` which returns all the layouts known by the linker as
implementing some ABI type. For instance, if I call this on my machine
(Linux/x64) I get this:
jshell> import java.lang.foreign.*;
jshell>
On 17/05/2023 08:58, Uwe Schindler wrote:
If we would change to Java 21 as compilation target, we may need to
adapt our code.
I believe that would be an experiment worth doing (if you can!), and
report back if you find any compilation problems.
E.g. using --release 17 effectively shields
On Wed, 17 May 2023 11:46:39 GMT, Per Minborg wrote:
> As the API has improved over the recent releases, not all `{@snippet ..}`
> sections have been kept in sync.
>
> This PR suggests all snippets used should be verified against real code that
> is placed in a new `snippet-files` folder and
On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore
wrote:
> As explained in [1], memory layouts and memory segments describe sizes using
> different units. Memory layouts use bits, whereas memory segments use bytes.
> This is historical: memory layouts were designed after the Mi
As explained in [1], memory layouts and memory segments describe sizes using
different units. Memory layouts use bits, whereas memory segments use bytes.
This is historical: memory layouts were designed after the Minimal LDL [2],
which allowed layout strings to be used to describe both memory
ed by heap segments, so that it is 4 for long[] and
> double[] on 32-bit platforms.
Maurizio Cimadamore has updated the pull request incrementally with one
additional commit since the last revision:
Fix max alignment constants
-
Changes:
- all: https://git.openjdk.org/jdk/pull/14007
On Tue, 16 May 2023 11:18:09 GMT, Maurizio Cimadamore
wrote:
> The FFM API exposes layout constants for Java primitives. Among those there
> are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of
> these layouts is set the same as their size (e.g
The FFM API exposes layout constants for Java primitives. Among those there are
constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these
layouts is set the same as their size (e.g. 8 bytes).
This is obviously correct on 64-bit platforms, but on 32-bit platform it is
not,
On 17/05/2023 08:28, Uwe Schindler wrote:
# You changed the lifetime abstractions in Java 20 and again in 21. To
me this is 2 rounds. After 19 people were not happy, so you added 20.
In 20 there was some additional cleanup (in my impression it was a
step back to Java 18 state just with
Hi Uwe,
* If there are changes again would that mean we get another preview
round? --- unfortunate!
This seems to be indeed the case for most of the stuff we finalize. E.g.
Loom and amber feature were finalized pretty much "as is" after a round
of very (very) light changes. In fact,
On 16/05/2023 19:03, - wrote:
For FFI, I would prefer some parts of the FFI, especially generic ones
like Indirect Var Handles, to be promoted from the preview status.
They are useful for non-FFI purposes.
These parts (e.g. the additional var handle combinators in
MethodHandles) are the only
ymbol in the first lookup, and, if that fails, proceeds to search
> the symbol in the provided lookup.
>
> We have considered alternatives to express this, such as a static factory
> `SymbolLookup::ofComposite` but settled on this because of the similarity
> with `Optional::or`.
ymbol in the first lookup, and, if that fails, proceeds to search
> the symbol in the provided lookup.
>
> We have considered alternatives to express this, such as a static factory
> `SymbolLookup::ofComposite` but settled on this because of the similarity
> with `Optional::or`.
On Tue, 16 May 2023 16:55:21 GMT, Paul Sandoz wrote:
>> I was trying to split the sentence so that we could get a compact javadoc
>> header for the factory. How much important is that?
>
> Not very IHMO. I was just trying to say the same thing you said with less
> words, which makes it more
On Tue, 16 May 2023 16:48:13 GMT, Paul Sandoz wrote:
>> This patch adds a simpler method for composing symbol lookups. It is common
>> for clients to chain multiple symbol lookups together, e.g. to find a symbol
>> in multiple libraries.
>>
>> A new instance method, namely `SymbolLookup::or`
On 16/05/2023 16:38, Uwe Schindler wrote:
It exists now since Java 14, where it first appeared as incubation. I
know theres still work on the foreign linker, but why aren't the
stable classes like MemorySegment, ValueLayout not public now?
Hi Uwe,
while I understand the frustration (and I'm
On Thu, 11 May 2023 10:00:39 GMT, Maurizio Cimadamore
wrote:
> As the title says, this patch fixes an issue with
> `MemorySegment::reinterpet`, which reports the customary "restricted method"
> section twice.
>
> I also fixed some wrong capitalization in
This patch adds a simpler method for composing symbol lookups. It is common for
clients to chain multiple symbol lookups together, e.g. to find a symbol in
multiple libraries.
A new instance method, namely `SymbolLookup::or` is added, which first searches
a symbol in the first lookup, and, if
On Thu, 11 May 2023 21:29:51 GMT, Maurizio Cimadamore
wrote:
> This patch fixes the JNI test for the enable native access flag, which was
> updated incorrectly as part of https://git.openjdk.org/jdk/pull/13863.
>
> The problem is that the test doesn't make global references out
This patch fixes the JNI test for the enable native access flag, which was
updated incorrectly as part of https://git.openjdk.org/jdk/pull/13863.
The problem is that the test doesn't make global references out of the local
ones before sharing them with another thread.
I could reproduce the
As the title says, this patch fixes an issue with `MemorySegment::reinterpet`,
which reports the customary "restricted method" section twice.
I also fixed some wrong capitalization in the text of the factories in
`Linker.Option`.
-
Commit messages:
- Initial push
Changes:
On Mon, 8 May 2023 11:10:36 GMT, Maurizio Cimadamore
wrote:
> Port of: https://git.openjdk.org/panama-foreign/pull/831
This pull request has now been integrated.
Changeset: ba9714d4
Author: Maurizio Cimadamore
URL:
https://git.openjdk.org/jdk/com
> Port of: https://git.openjdk.org/panama-foreign/pull/831
Maurizio Cimadamore has updated the pull request with a new target base due to
a merge or a rebase. The pull request now contains four commits:
- Merge branch 'master' into linker_restricted
- Address review comment
- Cleanup code
On Tue, 9 May 2023 11:11:36 GMT, Adam Sotona wrote:
>> Classfile API didn't handle transformations of class files version 50 and
>> below correctly.
>>
>> Proposed fix have two parts:
>> 1. Inflation of branch targets does not depend on StackMapTable attribute
>> presence for class file
On Tue, 9 May 2023 11:11:36 GMT, Adam Sotona wrote:
>> Classfile API didn't handle transformations of class files version 50 and
>> below correctly.
>>
>> Proposed fix have two parts:
>> 1. Inflation of branch targets does not depend on StackMapTable attribute
>> presence for class file
On Tue, 9 May 2023 11:11:36 GMT, Adam Sotona wrote:
>> Classfile API didn't handle transformations of class files version 50 and
>> below correctly.
>>
>> Proposed fix have two parts:
>> 1. Inflation of branch targets does not depend on StackMapTable attribute
>> presence for class file
On Mon, 8 May 2023 13:46:55 GMT, Maurizio Cimadamore
wrote:
> This is a tricky intermittent failure on one of our async file channel test.
>
> While the logic of the test is a bit hard to follow, I believe the test is
> supposed to work as follows:
>
> * in the main
On Mon, 8 May 2023 16:10:37 GMT, Maurizio Cimadamore
wrote:
> This is a port of: https://git.openjdk.org/panama-foreign/pull/830
This pull request has now been integrated.
Changeset: 7a3bea1f
Author: Maurizio Cimadamore
URL:
https://git.openjdk.org/jdk/com
This is a port of: https://git.openjdk.org/panama-foreign/pull/830
-
Commit messages:
- Initial push
Changes: https://git.openjdk.org/jdk/pull/13869/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=13869=00
Issue: https://bugs.openjdk.org/browse/JDK-8307629
Stats: 75 lines
> Port of: https://git.openjdk.org/panama-foreign/pull/831
Maurizio Cimadamore has updated the pull request incrementally with one
additional commit since the last revision:
Address review comment
-
Changes:
- all: https://git.openjdk.org/jdk/pull/13863/files
- new: ht
On Mon, 8 May 2023 12:17:44 GMT, Jorn Vernee wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comment
>
> src/java.base/share/classes/jdk/internal/foreign/abi/
Port of: https://git.openjdk.org/panama-foreign/pull/831
-
Commit messages:
- Cleanup code so that restricted method check is shared
- Initial push
Changes: https://git.openjdk.org/jdk/pull/13863/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=13863=00
Issue:
On Mon, 8 May 2023 11:10:36 GMT, Maurizio Cimadamore
wrote:
> Port of: https://git.openjdk.org/panama-foreign/pull/831
src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line
86:
> 84: }
> 85:
> 86: private final MethodHandle downcallHandle0(Class
On Mon, 8 May 2023 09:32:31 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Remove assertion, no longer true with teleport definition in MHP
>
> src/java.base/
On Sun, 7 May 2023 13:34:54 GMT, Chen Liang wrote:
>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based
>> implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance
>> interface)
>> 2.
Another way to help inference, in cases like this would be to break up
the method chain - as follows:
final Stream> stream = Stream.of(nestedDequeue,
nestedList);
final List> list = stream.toList();
In the above rewriting, now the target type Stream>
"drives" inference for Stream::of -
On Wed, 3 May 2023 17:44:55 GMT, Maurizio Cimadamore
wrote:
> This patch fixes `Utils::checkElementAlignment` to do the right thing for
> _all_ layouts.
>
> The current implementation is broken, as it only works correctly when the
> input layout is a value layout.
> Since
On Fri, 5 May 2023 13:08:33 GMT, Chen Liang wrote:
>> Also, perhaps @PaulSandoz knows more history on this one (I believe this
>> code predates FFM).
>
> Eh? I am not sure what you mean here. This is the essence of the patch, where
> the "TODO" above is fixed: lookup.findStaticVarHandle now
On Fri, 5 May 2023 13:03:14 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 74:
>>
>>> 72: @Override
>>> 73: public boolean isAccessModeSupported(AccessMode accessMode) {
>>> 74: var directTarget = this.directTarget;
>>
>> Why
On Fri, 5 May 2023 13:01:09 GMT, Maurizio Cimadamore
wrote:
>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>>
>> A few implementation-detail methods in VarHandle are now documented with the
>> implied constraints to avoid subtle problem
501 - 600 of 923 matches
Mail list logo
