On Fri, 4 Oct 2024 18:24:37 GMT, Chen Liang wrote:
>> src/java.base/share/classes/jdk/internal/constant/ArrayClassDescImpl.java
>> line 116:
>>
>>> 114: sb.append(componentDesc);
>>> 115: return sb.toString();
>>> 116: }
>>
>> Is there really that much benefit in lazily com
On Wed, 21 Aug 2024 20:25:07 GMT, Chen Liang wrote:
> @cl4es discovered that Stack Map generation in ClassFile API uses
> `componentType` and `arrayType` for `aaload` `aastore` instructions, which
> are currently quite slow. We can split out array class descriptors from class
> or interfaces t
On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee wrote:
> As discussed in the JBS issue:
>
> FFM upcall stubs embed a `Method*` of the target method in the stub. This
> `Method*` is read from the `LambdaForm::vmentry` field associated with the
> target method handle at the time
On Thu, 19 Sep 2024 12:20:13 GMT, Jorn Vernee wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target meth
On Tue, 1 Oct 2024 17:49:12 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Tue, 1 Oct 2024 16:22:36 GMT, Maurizio Cimadamore
wrote:
>> The issue with using a compile command is that it will then work globally.
>> So the benchmark would not really test much - besides checking that var
>> handle access is slow when `asType` cannot inline. What I was trying to do
>>
On Tue, 1 Oct 2024 06:28:02 GMT, David Holmes wrote:
>> In this case there is no classic release/acquire. Instead, we rely on other
>> properties: The `vmentry` field is loaded in
>> `MethodHandles::jump_to_lambda_form`, using a plain load. I believe a
>> load-acquire is not needed here becaus
On Tue, 1 Oct 2024 10:18:15 GMT, Maurizio Cimadamore
wrote:
>> The fix for JDK-8331865 introduced an accidental performance regression.
>> The main issue is that now *all* memory segment var handles go through some
>> round of adaptation.
>> Adapting a var handle results in a so called *indirec
On Sun, 29 Sep 2024 23:52:29 GMT, David Holmes wrote:
>> The `form` field is a final field; thus, all reads to that field is a
>> load-acquire. This load-load barrier is critical to ensure observing the
>> correct, non-null `vmentry` field value if the updated form is observed.
>>
>> Note that
On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann wrote:
> When investigating an intermittent NPE with an Oracle internal test on
> AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by
> `MethodHandles::jump_to_lambda_form` when trying to load the
> `MemberName::method`
On Tue, 24 Sep 2024 06:51:49 GMT, Alan Bateman wrote:
> For now, I think the proposed wording in this PR is okay.
Yes, I agree what I'm suggesting is out of scope for this PR.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/21067#discussion_r1773524153
On Tue, 24 Sep 2024 14:53:22 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
On Mon, 23 Sep 2024 16:35:18 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Reword doce
Marked as reviewed by jvernee (Re
On Mon, 23 Sep 2024 16:40:08 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Reword doce
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line
> 225:
>
>> 223:
On Mon, 23 Sep 2024 14:40:40 GMT, Jorn Vernee wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Add to specification and refine detection of PL GLs
>
> src/java.base/share/classes/java
On Mon, 23 Sep 2024 13:54:52 GMT, Per Minborg wrote:
>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last revision:
>
> Add to specification and refine detection of P
On Mon, 23 Sep 2024 13:37:07 GMT, Vladimir Kozelkov wrote:
>> Per Minborg 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 the merge/rebase. The pull request contains nine additional
>> com
On Mon, 23 Sep 2024 11:15:08 GMT, Maurizio Cimadamore
wrote:
>> Previously, the check threw an `IllegalArgumentException` when presented
>> with the above (or other) group layout with only padding layouts, but the
>> actual message differed. So, this change only changes the exception message
On Mon, 23 Sep 2024 11:45:23 GMT, Jorn Vernee wrote:
>> It is documented by the CS JEP: https://openjdk.org/jeps/176
>>
>>> It discovers its caller's class by invoking the
>>> sun.reflect.Reflection.getCallerClass method.
>>
>> CS set the preced
On Mon, 23 Sep 2024 09:39:00 GMT, David Holmes wrote:
>> We use "no caller class" in the CS methods, maybe it could be improved.
>>
>> I think "can not be determined" just begs questions. Is this a JDK
>> limitation, something I'm doing wrong, or something else, ... if you see
>> what I mean.
html
>>
>> Co-authored-by: Jorn Vernee
>
> src/java.base/share/classes/java/lang/doc-files/RestrictedMethods.html line
> 43:
>
>> 41: When a restricted method is invoked by > href="../../../../specs/jni/index.html">JNI code,
>>
On Fri, 20 Sep 2024 08:41:45 GMT, Maurizio Cimadamore
wrote:
> The javadoc of the `Linker` also states that:
>
> > [A group layout] G does not contain padding other than what is strictly
> > required to align
> > its non-padding layout elements, or to satisfy (2) [the size of {@code G}
> > is
On Tue, 17 Sep 2024 14:12:58 GMT, Per Minborg wrote:
> This PR prevents sequence layout with padding to be used with the Linker.
src/java.base/share/classes/java/lang/foreign/Linker.java line 252:
> 250: * the alignment constraint of {@code S} is set to its
> 251: * natural alignment,
>
On Thu, 19 Sep 2024 13:59:30 GMT, Maurizio Cimadamore
wrote:
>> This PR moves the section on restricted methods from the the javadoc of
>> `java.lang.foreign` package into a standalone static [javadoc
>> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.bas
On Thu, 19 Sep 2024 05:03:50 GMT, Amit Kumar wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> remove PC save/restore on s390
>
> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3063:
core Error Units
> Upcalls.panama_blank avgt 30 61.218 ± 0.554 ns/op
>
>
>
> As for the added TestUpcallStress test, it takes about 800 seconds to run
> this test on the dev machine I'm using, so I've set the timeout quite high.
> Since it runs for so long, I
On Wed, 18 Sep 2024 15:47:01 GMT, Maurizio Cimadamore
wrote:
> This PR moves the section on restricted methods from the the javadoc of
> `java.lang.foreign` package into a standalone static [javadoc
> page](https://cr.openjdk.org/~mcimadamore/jdk/restricted_javadoc_section/docs/api/java.base/j
On Tue, 17 Sep 2024 09:28:02 GMT, Claes Redestad wrote:
> This PR exploits the observation that in many of the cases where we call
> `methodType.invokerType()` we immediately translate it into a `Name[]` where
> the only effect is to create an array with an additional leading
> `BasicType.L_TY
On Mon, 16 Sep 2024 07:58:44 GMT, Claes Redestad wrote:
>> Simple internal refactor to load a few classes less on startup. Arguably
>> cleaner and avoids some iterator allocations.
>
> Claes Redestad has updated the pull request incrementally with one additional
> commit since the last revision
On Fri, 13 Sep 2024 15:40:46 GMT, Claes Redestad wrote:
> Simple internal refactor to load a few classes less on startup. Arguably
> cleaner.
src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2223:
> 2221: }
> :
> 2223: return makeHiddenClassDefi
On Tue, 10 Sep 2024 10:58:19 GMT, Claes Redestad wrote:
> Trivially remove a static optimization mapping for a non-existent method in
> LambdaMetafactory. The referenced method was refactored into a set of factory
> methods in java.lang.invoke.ConstantBootstraps before ever becoming a public
>
On Mon, 9 Sep 2024 23:52:41 GMT, Claes Redestad wrote:
> Switching to `invokeBasic` for type-check invokes in
> `BootstrapMethodInvokers` instead of `invokeExact` avoids some
> `MethodHandleNatives.linkMethod` calls during bootstrap. This brings a tiny
> but measurable once-per-bootstrap metho
On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore
wrote:
> The new test added by https://github.com/openjdk/jdk/pull/20854 fails
> spuriously.
> While JNI lookup is now moved into the static initializer of the
> `MappedMemoryUtils` class, this class might only get initialized while in the
On Fri, 6 Sep 2024 17:51:15 GMT, Jorn Vernee wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target meth
core Error Units
> Upcalls.panama_blank avgt 30 61.218 ± 0.554 ns/op
>
>
>
> As for the added TestUpcallStress test, it takes about 800 seconds to run
> this test on the dev machine I'm using, so I've set the timeout quite high.
> Since it runs for so
On Tue, 3 Sep 2024 17:52:35 GMT, Jorn Vernee wrote:
> - Adjust downcall stub sizes based on latest version. (per method described
> in https://github.com/openjdk/jdk/pull/12908)
> - Beef up test for large stubs to also cover this particular case.
This pull request has now been i
core Error Units
> Upcalls.panama_blank avgt 30 61.218 ± 0.554 ns/op
>
>
>
> As for the added TestUpcallStress test, it takes about 800 seconds to run
> this test on the dev machine I'm using, so I've set the timeout quite high.
> Since it runs for so
On Wed, 4 Sep 2024 12:46:21 GMT, Fei Yang wrote:
>> Were you able to reproduce the original issue on RISC-V?
>
>> Were you able to reproduce the original issue on RISC-V?
>
> Yeah. I can reproduce similar crash on linux-riscv64 platform running this
> new test as well.
Ok, I'll add riscv as on
core Error Units
> Upcalls.panama_blank avgt 30 61.218 ± 0.554 ns/op
>
>
>
> As for the added TestUpcallStress test, it takes about 800 seconds to run
> this test on the dev machine I'm using, so I've set the timeout quite high.
> Since it runs for so
core Error Units
> Upcalls.panama_blank avgt 30 61.218 ± 0.554 ns/op
>
>
>
> As for the added TestUpcallStress test, it takes about 800 seconds to run
> this test on the dev machine I'm using, so I've set the timeout quite high.
> Since it runs for so
- Adjust downcall stub sizes based on latest version. (per method described in
https://github.com/openjdk/jdk/pull/12908)
- Beef up test for large stubs to also cover this particular case.
-
Commit messages:
- use junit
- make test more rebust
- add test
- adjust downcall stub si
On Wed, 4 Sep 2024 06:14:57 GMT, Fei Yang wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target method handle at the time when the upcall s
On Wed, 4 Sep 2024 11:39:10 GMT, Jorn Vernee wrote:
>> src/hotspot/share/prims/upcallLinker.cpp line 142:
>>
>>> 140: Handle exception_h(Thread::current(), exception);
>>> 141: java_lang_Throwable::print_stack_trace(exception_h, tty);
>>> 142:
On Wed, 4 Sep 2024 01:29:22 GMT, David Holmes wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target method handle at the time when the upca
On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee wrote:
> As discussed in the JBS issue:
>
> FFM upcall stubs embed a `Method*` of the target method in the stub. This
> `Method*` is read from the `LambdaForm::vmentry` field associated with the
> target method handle at the time
On Tue, 3 Sep 2024 04:52:08 GMT, Amit Kumar wrote:
>> As discussed in the JBS issue:
>>
>> FFM upcall stubs embed a `Method*` of the target method in the stub. This
>> `Method*` is read from the `LambdaForm::vmentry` field associated with the
>> target method handle at the time when the upcall
On Thu, 8 Aug 2024 10:51:59 GMT, Martin Doerr wrote:
> Can't we do these nasty loads in C++ code and use set_vm_result_2 in
> UpcallLinker::on_entry?
That's what I tried. I got a ~20% hit to execution time.
> I guess that upcalls are less performance critical
Why so? They are certainly much m
On Tue, 6 Aug 2024 17:26:55 GMT, Jorn Vernee wrote:
> As discussed in the JBS issue:
>
> FFM upcall stubs embed a `Method*` of the target method in the stub. This
> `Method*` is read from the `LambdaForm::vmentry` field associated with the
> target method handle at the time
As discussed in the JBS issue:
FFM upcall stubs embed a `Method*` of the target method in the stub. This
`Method*` is read from the `LambdaForm::vmentry` field associated with the
target method handle at the time when the upcall stub is generated. The MH
instance itself is stashed in a global J
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code
On Fri, 5 Jul 2024 14:23:50 GMT, Jorn Vernee wrote:
>> Hannes Greule has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> address comments
>
> I think this needs a CSR, to document the change i
This test spawns 2 forked processes, which then try to trigger a code cache OOM
in FFM hotspot code. Even without `-Xcomp`, the test is already pretty slow,
which increases dramatically with `-Xcomp`, since startup Java code has to be
compiled 3 times, once for the main test process, and then 2
On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote:
> We are seeing some failures of this test in our CI, particularly on Windows
> machines, which are known to starve out certain threads.
>
> To make sure the compiler threads get a chance to work, I've added `-Xbatch`
&g
On Thu, 25 Jul 2024 10:58:42 GMT, Jorn Vernee wrote:
> We are seeing some failures of this test in our CI, particularly on Windows
> machines, which are known to starve out certain threads.
>
> To make sure the compiler threads get a chance to work, I've added `-Xbatch`
&g
We are seeing some failures of this test in our CI, particularly on Windows
machines, which are known to starve out certain threads.
To make sure the compiler threads get a chance to work, I've added `-Xbatch` to
the flags with which the test runs (this was missed in the original PR). I've
also
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
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 Wed, 17 Jul 2024 13:44:58 GMT, Aleksey Shipilev wrote:
> > @shipilev Would you re-review this patch, or are you no longer interested
> > now that `@Stable` is removed?
>
> I am not sure I understand the performance implications for this change. I
> can see the optimization for avoiding `Nam
On Tue, 16 Jul 2024 19:59:41 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaForm.java line 1388:
>>
>>> 1386: Name withIndex(int i) {
>>> 1387: if (i == this.index) return this;
>>> 1388: return new Name(i, type, function, arguments,
On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. On a strategic view, this index field should just become final
>> so that `Name` becomes eligible for value class migration once valhalla
>> comes. Thi
On Tue, 16 Jul 2024 03:10:29 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. On a strategic view, this index field should just become final
>> so that `Name` becomes eligible for value class migration once valhalla
>> comes. Thi
On Tue, 16 Jul 2024 15:12:15 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 Tue, 16 Jul 2024 15:00:04 GMT, Doug Simon wrote:
>> Jorn Vernee has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> JVMCI support
>
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/hotspot/HotSpotReso
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 Tue, 16 Jul 2024 14:46:13 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 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
1 - 100 of 916 matches
Mail list logo
