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
On Thu, 5 Sep 2024 14:33:56 GMT, Emanuel Peter wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Some cleanups.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorMathUtils.java
> line 78:
>
>>
> 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:
fixed spelling to be consistent with the rest of the man page.
-
Commit messages:
- 8337422: spelling error in jlink documentation
Changes: https://git.openjdk.org/jdk/pull/20882/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20882&range=00
Issue: https://bugs.openjdk.or
On Thu, 5 Sep 2024 14:31:39 GMT, Emanuel Peter 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?
>
> What is not app
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 Wed, 7 Aug 2024 00:02:46 GMT, Joe Darcy wrote:
>> First pass at adding some quality of implementation discussions around the
>> overridable methods of Object.
>
> Joe Darcy has updated the pull request with a new target base due to a merge
> or a rebase. The incremental webrev excludes the u
*Hi Archie,*
Thanks to your valuable suggestions, I was able to come up with a much more
appropriate test, and I’ve learned a great deal in the process. I truly
appreciate your insights! While this approach is clearly a significant
improvement over the previous one, I still feel there might be con
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 Fri, 6 Sep 2024 01:01:11 GMT, Chen Liang wrote:
>> Do I need to declare it as ACC_INTERFACE? Many utility classes do this.
>
> interface has extra restrictions that can fail class validation, such as
> fields must be public static final. So I recommend just using abstract class.
Thanks, I le
> 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 Fri, 6 Sep 2024 00:45:14 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line
>> 1288:
>>
>>> 1286: if (staticConcat) {
>>> 1287: clb.withSuperclass(CD_Object)
>>> 1288:
> 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 Fri, 6 Sep 2024 00:21:07 GMT, Shaojin Wen wrote:
>> A small optimization, when CompactStrings is turned off, the coder method is
>> not generated, which improves the startup performance
>
> Shaojin Wen has updated the pull request incrementally with one additional
> commit since the last rev
On Thu, 5 Sep 2024 23:37:30 GMT, Chen Liang wrote:
>> Shaojin Wen has updated the pull request with a new target base due to a
>> merge or a rebase. The pull request now contains 12 commits:
>>
>> - Merge remote-tracking branch 'upstream/master' into
>> optim_concat_factory_202408
>>
>>
> A small optimization, when CompactStrings is turned off, the coder method is
> not generated, which improves the startup performance
Shaojin Wen has updated the pull request incrementally with one additional
commit since the last revision:
add java doc
-
Changes:
- all: http
On Thu, 5 Sep 2024 21:05:38 GMT, Brian Burkhalter wrote:
> Make explicit how the `java.io.File` methods `isDirectory`, `isFile`, and
> `isHidden` behave when the `File` represents a symbolic link.
If the `File` is a symbolic link, it looks after all that for most methods, the
final target of l
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/jdk/internal/access/JavaLangAccess.java line 455:
> 453: Object stringConc
On Thu, 5 Sep 2024 23:39:58 GMT, Shaojin Wen wrote:
>> src/java.base/share/classes/java/lang/System.java line 2641:
>>
>>> 2639: }
>>> 2640:
>>> 2641: public byte stringInitCoder() {
>>
>> Why do we expose this as a coder instead of other ways, such as a `boolean
>> ha
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
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 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:
> 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
`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
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
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**
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
> 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
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
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 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
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 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
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
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
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.
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.
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 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
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
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
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
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 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:
> 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
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
> 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 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
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 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 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 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
> 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 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
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
> 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: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:
Lower the mismatch threshold
-
Cha
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
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 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:
>
> 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
> 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
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
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
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 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 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 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 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
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
> 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
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
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
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 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
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
> 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 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
> 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 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 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
> 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
-
> 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
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
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
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 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
> 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, 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
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, 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: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
1 - 100 of 119 matches
Mail list logo
