On Thu, 5 Sep 2024 00:48:26 GMT, Shaojin Wen wrote:
>> Use fast path for ascii characters 1 to 127 to improve the performance of
>> writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> suggesti
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Update
src/java.base/share/classes/jdk/internal
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
On Tue, 3 Sep 2024 13:09:13 GMT, Emanuel Peter wrote:
> You did in fact add `java/lang` methods. I think you need to add tests for
> all of those. As well. That's going to be even more code to review.
Hi @eme64 , As Paul suggested in offline mail chain, lets restrict the changes
with this patc
On Tue, 3 Sep 2024 22:18:20 GMT, Sandhya Viswanathan
wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review comments resolved
>
> src/hotspot/cpu/x86/x86.ad line 10684:
>
>> 10682: match(Set dst (SaturatingSub
A few trivial(?) cleanups to `java.lang.runtime.ObjectMethods`:
- Avoid `MethodType.fromDescriptorString` which needs a classloader
- Use `MethodHandles.zero`
- Remove unused static `MethodHandles` and `MethodTypes`
-
Commit messages:
- 8339592: Simplify and remove unused code in Obj
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
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
> Hi All,
>
> As per the discussion on panama-dev mailing list[1], patch adds the support
> following new vector operators.
>
>
> . SUADD : Saturating unsigned addition.
> . SADD: Saturating signed addition.
> . SUSUB : Saturating unsigned subtraction.
> . SSUB:
> The test is inspired from [FFM API's
> TestNulls](https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java),
> I customized their Null checking framework it to work with ClassFile API.
>
> The framework for for testing an API in bulk, so that all methods are
> reflectiv
On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters wrote:
>> make/StaticLibs.gmk line 71:
>>
>>> 69: # libsspi_bridge has name conflicts with sunmscapi
>>> 70: BROKEN_STATIC_LIBS += sspi_bridge
>>> 71: # These libs define DllMain which conflict with Hotspot
>>
>> I'm not aware of the DllMain
On Wed, 4 Sep 2024 23:03:23 GMT, Jiangli Zhou wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamically, l
On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore
wrote:
> Scoped methods are critical methods in the FFM API where memory is accessed
> in a potentially unsafe way. When closing shared arenas, we look at threads
> in the middle of a scoped operation involving that arena, and if we find one
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Wed, 4 Sep 2024 23:28:10 GMT, Jiangli Zhou wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamically, l
On Wed, 4 Sep 2024 23:24:13 GMT, Jiangli Zhou wrote:
>> As a prerequisite for Hermetic Java, we need a statically linked `java`
>> launcher. It should behave like the normal, dynamically linked `java`
>> launcher, except that all JDK native libraries should be statically, not
>> dynamically, l
On Tue, 3 Sep 2024 12:50:01 GMT, Magnus Ihse Bursie wrote:
> As a prerequisite for Hermetic Java, we need a statically linked `java`
> launcher. It should behave like the normal, dynamically linked `java`
> launcher, except that all JDK native libraries should be statically, not
> dynamically,
On Thu, 5 Sep 2024 00:48:26 GMT, Shaojin Wen wrote:
>> Use fast path for ascii characters 1 to 127 to improve the performance of
>> writing Utf8Entry to BufferWriter.
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> suggesti
> Scoped methods are critical methods in the FFM API where memory is accessed
> in a potentially unsafe way. When closing shared arenas, we look at threads
> in the middle of a scoped operation involving that arena, and if we find one,
> we make it fail (by installing an async handshake on that
On Thu, 5 Sep 2024 09:55:46 GMT, Alan Bateman wrote:
> Do the MMU_* functions still need to be jni-exported?
I've now dropped JNIEXPORT, but kept JNICALL, as that is used to set
`__stdcall` (at least on Windows).
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussi
On Thu, 5 Sep 2024 08:34:11 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request with a new target base due to a
> merge or a rebase. The i
On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore
wrote:
>> Scoped methods are critical methods in the FFM API where memory is accessed
>> in a potentially unsafe way. When closing shared arenas, we look at threads
>> in the middle of a scoped operation involving that arena, and if we find
On Thu, 5 Sep 2024 11:29:41 GMT, Alan Bateman wrote:
>> Maurizio Cimadamore has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Address review comments
>
> test/jdk/java/foreign/TestMappedHandshake.java line 90:
>
>> 88:
>> 89:
On Thu, 29 Aug 2024 14:38:20 GMT, Shaojin Wen wrote:
> Use fast path for ascii characters 1 to 127 to improve the performance of
> writing Utf8Entry to BufferWriter.
This pull request has now been integrated.
Changeset: cb9f5c57
Author:Shaojin Wen
Committer: Claes Redestad
URL:
ht
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Add optimized checking
-
Changes:
On Thu, 5 Sep 2024 11:15:22 GMT, Maurizio Cimadamore
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 10 additional
>> com
Hi Kim,
On 05/09/2024 06:10, 김민주 wrote:
If I use an external lock, T1 will block in the |await()| state, but T2,
T3, and T4 will be waiting for the external lock rather than entering
the |await()| state in |put()|. This would prevent me from simulating
the specific behavior I’m trying to test.
On Wed, 4 Sep 2024 11:55:50 GMT, Jorn Vernee wrote:
>> It does return. `ShouldNotReachHere` is used to crash the VM.
>
> `fatal()` might be better here. I could change it.
Yes please do.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r1745356400
On Wed, 4 Sep 2024 22:41:38 GMT, Chen Liang wrote:
> Currently, raw bytecode access goes through multiple wrappers, include one
> from ClassFile API and another ByteBuffer for merged big endian value reads.
> We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper)
> for saf
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Update benchmarks
-
Changes:
- a
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Consolidate logic in one method
-
On Wed, 4 Sep 2024 10:14:30 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Consolidate logic in one method
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg wrote:
> This PR proposes to handle smaller FFM copy operations with Java code rather
> than transitioning to native code. This will improve performance. In this PR,
> copy operations involving zero to 63 bytes will be handled by Java code.
>
> Here
> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on macOS,
> a few times this error occurs :
>
> java.lang.RuntimeException: Cannot allocate memory
>at java.base/java.lang.ProcessHandleImpl.getProcessPids0(Native Method)
>at
> java.base/java.lang.ProcessHandl
On Thu, 5 Sep 2024 13:20:11 GMT, Matthias Baesken wrote:
>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on
>> macOS, a few times this error occurs :
>>
>> java.lang.RuntimeException: Cannot allocate memory
>>at java.base/java.lang.ProcessHandleImpl.getProcessPids
> Please review this fix for cgroups-based metrics reporting in the
> `jdk.internal.platform` package. This fix is supposed to address wrong
> reporting of certain limits if the limits aren't set at the leaf nodes.
>
> For example, on cg v2, the memory limit interface file is `memory.max`.
> Co
On Thu, 5 Sep 2024 06:24:46 GMT, Shaojin Wen wrote:
>> Currently, raw bytecode access goes through multiple wrappers, include one
>> from ClassFile API and another ByteBuffer for merged big endian value reads.
>> We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper)
>> fo
On Thu, 5 Sep 2024 13:22:53 GMT, Claes Redestad wrote:
>> src/java.base/share/classes/jdk/internal/classfile/impl/RawBytecodeHelper.java
>> line 235:
>>
>>> 233: * we have a valid opcode.
>>> 234: */
>>> 235: public boolean next() {
>>
>> In C1, this cannot be inlined. See if you
Hi,
I'd also like to add here that Condition::await() is allowed to return
spuriously, leading to a reacquisition, and a subsequent release waiting to be
woken again, which would change the order from potentially being "next to run"
to becoming "last to run". At least this is the case as I read
On Thu, 5 Sep 2024 08:19:44 GMT, Claes Redestad wrote:
> A few trivial(?) cleanups to `java.lang.runtime.ObjectMethods`:
> - Avoid `MethodType.fromMethodDescriptorString` which needs a classloader
> - Use `MethodHandles.zero`
> - Remove unused static `MethodHandles` and `MethodTypes`
Marked as r
On Thu, 5 Sep 2024 13:31:21 GMT, Chen Liang wrote:
>> I don't think we should worry too much about making C1 inline more
>> aggressively.
>
> C2 needs 1 calls to inline this method, so wenshao is worried. However,
> this method call is almost always followed by a huge switch to handle
> di
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
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
Hi Viktor, hi Daniel,
Thank you both for your helpful feedback and insightful explanations.
Viktor, your point about Condition::await() and spurious wakeups has given
me a lot to think about. I now better understand why strict FIFO ordering
is challenging, especially given the possibility of spur
On Thu, 5 Sep 2024 13:40:51 GMT, Claes Redestad wrote:
>> C2 needs 1 calls to inline this method, so wenshao is worried. However,
>> this method call is almost always followed by a huge switch to handle
>> different opcode, so I doubt how much of a difference inlining brings.
>>
>> But wen
On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore
wrote:
>> Scoped methods are critical methods in the FFM API where memory is accessed
>> in a potentially unsafe way. When closing shared arenas, we look at threads
>> in the middle of a scoped operation involving that arena, and if we find
On Thu, 5 Sep 2024 08:34:36 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Thu, 5 Sep 2024 08:34:36 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> As per the discussion on panama-dev mailing list[1], patch adds the support
>> following new vector operators.
>>
>>
>> . SUADD : Saturating unsigned addition.
>> . SADD: Saturating signed addition.
>>
On Thu, 5 Sep 2024 07:42:26 GMT, Jatin Bhateja wrote:
>> src/hotspot/share/opto/vectornode.hpp line 634:
>>
>>> 632: virtual int Opcode() const;
>>> 633: };
>>> 634:
>>
>> This could also be a separate PR. Or are they somehow inseparable from the
>> "saturation" changes?
>
> Not applicable
On Fri, 30 Aug 2024 20:59:18 GMT, Brian Burkhalter wrote:
> Return the final path derived from the string returned by `canonicalize0()`.
This pull request has now been integrated.
Changeset: 042053c3
Author:Brian Burkhalter
URL:
https://git.openjdk.org/jdk/commit/042053c3a82e9fbd4c6
On Thu, 5 Sep 2024 14:04:19 GMT, Shaojin Wen wrote:
>> Yes, things like storing `endBci()` to a local variable can be great if it
>> both reduces code size and improves interpreter/C1 speed - but don't over-do
>> it as it's likely never-ending work for a kind of optimizations leyden might
>> m
Hi Kim,
I'll add some of my personal thoughts on the matter.
What you're typically after when you're reaching for "fair" is not a strict
linearizable order (because such order needs external, additional, coordination
to be observable), but rather what you want is to avoid the risk of "unbounded
> Currently, raw bytecode access goes through multiple wrappers, include one
> from ClassFile API and another ByteBuffer for merged big endian value reads.
> We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper)
> for safer access.
>
> RawBytecodeHelper is also restructure
> 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 i
On Wed, 4 Sep 2024 17:03:32 GMT, Martin Doerr wrote:
>> Tier1 test are fine with/without "saving & restoring" return_pc;
>
> I found it:
> https://github.com/openjdk/jdk/blob/433f6d8a0643b59663bf76c0f3a2af27a6cc56b7/src/hotspot/cpu/s390/gc/g1/g1BarrierSetAssembler_s390.cpp#L238
> Called here:
>
Hi Kim,
I think there may be an issue with your test. Specifically, this code is
suspect:
// Wait for the producer thread to enter BLOCKED state
// This ensures that the thread is waiting on the full queue
while (thread.getState() == State.RUNNABLE || thread.getState() ==
State.NEW);
On Thu, 5 Sep 2024 15:39:07 GMT, Chen Liang wrote:
>> Currently, raw bytecode access goes through multiple wrappers, include one
>> from ClassFile API and another ByteBuffer for merged big endian value reads.
>> We can merge the ByteBuffer =into the ClassFile API one (RawBytecodeHelper)
>> for
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Lower the mismatch threshold
-
Cha
On Thu, 5 Sep 2024 17:21:32 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last
> This PR proposes to improve the performance of `MemorySegment::mismatch` by
> using Java code rather than transitioning to native code.
Per Minborg has updated the pull request incrementally with one additional
commit since the last revision:
Fix errors in a benchmark
-
Change
On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last
> This PR proposes to add a JDK-specific monitoring and management interface
> for the virtual thread scheduler. The interface is named
> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.management/jdk/management/VirtualThreadSchedulerMXBean.html)
> an
On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last
On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last
On Thu, 5 Sep 2024 17:54:46 GMT, Alan Bateman wrote:
>> This PR proposes to add a JDK-specific monitoring and management interface
>> for the virtual thread scheduler. The interface is named
>> [VirtualThreadSchedulerMXBean](https://download.java.net/java/early_access/loom/docs/api/jdk.manageme
On Thu, 5 Sep 2024 17:47:16 GMT, Per Minborg wrote:
>> This PR proposes to improve the performance of `MemorySegment::mismatch` by
>> using Java code rather than transitioning to native code.
>
> Per Minborg has updated the pull request incrementally with one additional
> commit since the last
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
On Thu, 5 Sep 2024 18:02:32 GMT, Maurizio Cimadamore
wrote:
>> Per Minborg has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fix errors in a benchmark
>
> src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java
> line
On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore
wrote:
> Scoped methods are critical methods in the FFM API where memory is accessed
> in a potentially unsafe way. When closing shared arenas, we look at threads
> in the middle of a scoped operation involving that arena, and if we find one
On Thu, 5 Sep 2024 17:59:50 GMT, David M. Lloyd wrote:
> The API docs don't seem to specify what a value of `-1` means; is it meant to
> indicate "not known"? It seems like other implementations are returning e.g.
> `MAX_VALUE` sometimes too; is that worth calling out in the doc for
> `getPara
On Tue, 3 Sep 2024 07:52:44 GMT, Per Minborg wrote:
> This PR proposes to handle smaller FFM copy operations with Java code rather
> than transitioning to native code. This will improve performance. In this PR,
> copy operations involving zero to 63 bytes will be handled by Java code.
>
> Here
On Thu, 5 Sep 2024 13:20:11 GMT, Matthias Baesken wrote:
>> When running jtreg test java/lang/ProcessHandle/PermissionTest.java on
>> macOS, a few times this error occurs :
>>
>> java.lang.RuntimeException: Cannot allocate memory
>>at java.base/java.lang.ProcessHandleImpl.getProcessPids
> Many constants are cluttered in `ClassFile`. However, only a few of them are
> ever used by regular users, most notably `ACC_` flags and `JAVA_X_VERSION`
> constants. All other constants are specific and should live in more local
> locations, such as getters that return these constants.
>
> T
Good point, Archie—I completely forgot to mention the fact that polling thread
state doesn't necessarily ensure that the thread has been enqueued once the
thread state is moved to blocking/waiting.
Thread state polling aside, for as long as Condition::await() is allowed to
spuriously wake, FIFO
> The goal of this PR is to implement an x86_64 intrinsic for
> java.lang.Math.tanh() using libm
>
> Benchmark (ops/ms) | Stock JDK | Tanh intrinsic | Speedup
> -- | -- | -- | --
> MathBench.tanhDouble | 70900 | 95618 | 1.35x
Srinivas Vamsi Parasa has updated the pull request incrementally with
On Tue, 3 Sep 2024 22:55:18 GMT, Joe Darcy wrote:
>> Srinivas Vamsi Parasa has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Add stub initialization and extra tanh tests
>
> test/jdk/java/lang/Math/HyperbolicTests.java line 984:
>
>> 982:
On Wed, 4 Sep 2024 00:01:09 GMT, Joe Darcy wrote:
> If the test is going to use randomness, then its jtreg tags should include
>
> `@key randomness`
>
> and it is preferable to use jdk.test.lib.RandomFactory to get and Random
> object since that handles printing out a key so the random sequenc
On Thu, 5 Sep 2024 09:50:49 GMT, Magnus Ihse Bursie wrote:
> Well, but your proof-of-concept only supports clang on linux, where you have
> enabled symbol hiding.
The hermetic-java-runtime branch doesn't have general symbol hiding enabled.
That's why I'm wondering what the issues are with thes
Apologies in advance if I'm misunderstanding anything...
On Thu, Sep 5, 2024 at 2:05 PM Viktor Klang
wrote:
> Thread state polling aside, for as long as Condition::await() is allowed
> to spuriously wake, FIFO just cannot be "guaranteed".
What about this statement in the Javadoc for Reentrant
Archie,
I should've been more specific—Condition-as-implemented-by-ReentrantLock (in
fair mode) provides stronger (for some definition of stronger) semantics that
the Condition interface specifies.
Since it's related, I've recently integrated a hardening of AQS and AQLS
reacquisition logic in
On Thu, 5 Sep 2024 05:06:55 GMT, Julian Waters wrote:
>> make/StaticLibs.gmk line 71:
>>
>>> 69: # libsspi_bridge has name conflicts with sunmscapi
>>> 70: BROKEN_STATIC_LIBS += sspi_bridge
>>> 71: # These libs define DllMain which conflict with Hotspot
>>
>> I'm not aware of the DllMain
On Thu, 5 Sep 2024 10:03:19 GMT, Magnus Ihse Bursie wrote:
>> make/StaticLibs.gmk line 118:
>>
>>> 116: OPTIMIZATION := HIGH, \
>>> 117: STATIC_LAUNCHER := true, \
>>> 118: LDFLAGS := $(JAVASTATIC_LINK_LDFLAGS), \
>>
>> I could be missing something, but I don't see where is
>> $JAV
On Thu, 5 Sep 2024 09:57:15 GMT, Magnus Ihse Bursie wrote:
>> make/modules/java.desktop/lib/AwtLibraries.gmk line 176:
>>
>>> 174:
>>> 175: ifneq ($(ENABLE_HEADLESS_ONLY), true)
>>> 176: # We cannot link with both awt_headless and awt_xawt at the same
>>> time
>>
>> Just a note on that.
Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
`isHidden` behave when the `File` represents a symbolic link.
-
Commit messages:
- 8339574: Behavior of File.is{Directory,File,Hidden} is not documented with
respect to symlinks
Changes: https://git.openjdk.
Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it with
JavaFX instead.
See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
openjdk/jfx#1529 for the JavaFX PR that will include the module with JavaFX.
That PR describes the needed test scenarios.
This PR d
On Mon, 12 Aug 2024 17:22:47 GMT, Kevin Rushforth wrote:
> Deprecate the `jdk.jsobject` module for removal from the JDK, and ship it
> with JavaFX instead.
>
> See [JDK-8337280](https://bugs.openjdk.org/browse/JDK-8337280) / PR
> openjdk/jfx#1529 for the JavaFX PR that will include the module
On Thu, 5 Sep 2024 05:07:12 GMT, Shaojin Wen wrote:
>> A small optimization to improve the performance of
>> jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last revision:
>
> remove benc
This fixes some of the recently discovered [issues] with the block variants of
the specification tags. While reviewing, please check the proposed changes
against the actual specifications. Since the specifications for JDK 23 are not
yet available in the HTML format, you can use the specification
On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo wrote:
> This fixes some of the recently discovered [issues] with the block variants
> of the specification tags. While reviewing, please check the proposed changes
> against the actual specifications. Since the specifications for JDK 23 are
> not y
On Wed, 4 Sep 2024 00:36:39 GMT, Shaojin Wen wrote:
>> A small optimization, optimize the BufferWriter implementation and use of
>> ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request incrementally with two additional
> commits since the last revision:
>
>
On Thu, 5 Sep 2024 21:46:34 GMT, Pavel Rappo wrote:
> This fixes some of the recently discovered [issues] with the block variants
> of the specification tags. While reviewing, please check the proposed changes
> against the actual specifications. Since the specifications for JDK 23 are
> not y
On Thu, 5 Sep 2024 22:01:52 GMT, Jonathan Gibbons wrote:
> possibly for later, a separate pass might be to review and make consistent
> the use of `{@code }` in the tags, such as in `The ... Attribute`
For example, the addition `@jls 15.20.2 The instanceof Operator` in this patch
does not wrap
On Thu, 5 Sep 2024 22:08:13 GMT, Chen Liang wrote:
> > possibly for later, a separate pass might be to review and make consistent
> > the use of `{@code }` in the tags, such as in `The ... Attribute`
>
>
>
> For example, the addition `@jls 15.20.2 The instanceof Operator` in this
> patch doe
> A small optimization, optimize the BufferWriter implementation and use of
> ClassFile, provide faster patchInt and skip
Shaojin Wen has updated the pull request with a new target base due to a merge
or a rebase. The pull request now contains 13 commits:
- Merge remote-tracking branch
'origi
A small optimization, when CompactStrings is turned off, the coder method is
not generated, which improves the startup performance
-
Commit messages:
- Update src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java
- Update src/java.base/share/classes/java/lang/invoke
On Tue, 27 Aug 2024 05:08:53 GMT, Shaojin Wen wrote:
> A small optimization, when CompactStrings is turned off, the coder method is
> not generated, which improves the startup performance
The `JLA.stringInitCoder() != 0` check should probably be the first thing in
this method, so that **C2**
On Thu, 5 Sep 2024 22:47:00 GMT, Shaojin Wen wrote:
>> A small optimization, optimize the BufferWriter implementation and use of
>> ClassFile, provide faster patchInt and skip
>
> Shaojin Wen has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now
`AbstractInstruction` has a redundant `size` field unnecessary for the majority
of instructions. We should add this field to the 2 switch instructions that
need it only.
-
Commit messages:
- 8339519: Remove size field from instructions
Changes: https://git.openjdk.org/jdk/pull/208
> This is a follow-up to PR #20273, which improves performance when the number
> of parameters exceeds 20.
>
> When the number of parameters is large, the possibility of reuse will be
> lower, so we can use the static concat method and write the length and coder
> directly into the bytecode to
On Tue, 27 Aug 2024 05:08:53 GMT, Shaojin Wen wrote:
> A small optimization, when CompactStrings is turned off, the coder method is
> not generated, which improves the startup performance
src/java.base/share/classes/java/lang/System.java line 2641:
> 2639: }
> 2640:
> 2641:
On Thu, 5 Sep 2024 23:20:02 GMT, Chen Liang wrote:
>> A small optimization, when CompactStrings is turned off, the coder method is
>> not generated, which improves the startup performance
>
> src/java.base/share/classes/java/lang/System.java line 2641:
>
>> 2639: }
>> 2640:
>> 2641
On Thu, 5 Sep 2024 23:22:01 GMT, Shaojin Wen wrote:
>> This is a follow-up to PR #20273, which improves performance when the number
>> of parameters exceeds 20.
>>
>> When the number of parameters is large, the possibility of reuse will be
>> lower, so we can use the static concat method and w
1 - 100 of 119 matches
Mail list logo
