Re: RFR: 8339576: Speed up raw bytecode processing in ClassFile API

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

Re: RFR: 8338890: Add monitoring/management interface for the virtual thread scheduler [v2]

> 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

Re: RFR: 8339168: Optimize ClassFile Util slotSize [v8]

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

Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Awesome, thank you guys. -- Marko [cid:Infobip_logo_vertical_signature_e28e13d2-255b-4571-a70c-8292f2d75c0b.png] Marko Bakšić Software Engineer E marko.bak...@infobip.com M A Utinjska 29A, 1 Zagreb, Croatia www.infobip.com _

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher

On Wed, 4 Sep 2024 23:06:00 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

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Daniel I hope you're doing well. I wanted to follow up on a previous message I sent. Since this is my first time contributing to OpenJDK, I realized I might not have communicated the issue clearly, and I wanted to provide more context about the situation I encountered. In the put() method o

Re: RFR: 8339168: Optimize ClassFile Util slotSize [v8]

> 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 benchmark - Changes: - all: https://git.openjdk.org/j

Re: RFR: 8339168: Optimize ClassFile Util slotSize [v7]

> 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: optimize parameterSlots - Changes: - all: https://git.openjd

Re: RFR: 8339576: Speed up raw bytecode processing in ClassFile API

On Thu, 5 Sep 2024 02:31:48 GMT, ExE Boss 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 s

Re: RFR: 8339576: Speed up raw bytecode processing in ClassFile API

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

RFR: 8339576: Speed up raw bytecode processing in ClassFile API

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 restructured so we avoi

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v21]

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

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v21]

> 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: suggestion from @liach - Changes: - all: https://git.open

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher

On Tue, 3 Sep 2024 12:51:13 GMT, Magnus Ihse Bursie wrote: > @jianglizhou Can you please check if there are any other contributors that > should be acknowledged? Thanks for asking! I checked all the related changes in https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. Followi

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher

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,

Re: RFR: 8339168: Optimize ClassFile Util slotSize [v6]

On Wed, 4 Sep 2024 23:25:30 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 with a new target base due to a > merge or a rebase. The incremental webrev excludes t

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher

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,

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

On Wed, 4 Sep 2024 23:14:35 GMT, Shaojin Wen wrote: >> test/jdk/java/lang/String/CountNonZeroAscii.java line 35: >> >>> 33: * @modules java.base/jdk.internal.access >>> 34: * @summary test latin1 String countNonZeroAscii >>> 35: * @run testng/othervm -XX:+CompactStrings CountNonZeroAscii >>

Re: RFR: 8339480: Build static-jdk image with a statically linked launcher

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,

Re: RFR: 8339168: Optimize ClassFile Util slotSize [v6]

> A small optimization to improve the performance of > jdk.internal.classfile.impl.Util#slotSize/isDoubleSlot Shaojin Wen 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 pul

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

On Wed, 4 Sep 2024 18:09:31 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> from @cl4es 's suggestion > > test/jdk/java/lang/String/CountNonZeroAscii.java line 35: > >> 33: * @modules java.base/jdk

Integrated: 8338937: Optimize the string concatenation of ClassDesc

On Sun, 25 Aug 2024 13:36:34 GMT, Shaojin Wen wrote: > The string concatenation of java.base module is implemented based on > StringBuilder, which will result in extra object allocation and slow > performance. We can solve this problem by using String.concat method and > StringConcatHelper to

Re: RFR: 8339260: Move rarely used constants out of ClassFile [v3]

> 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

RFR: 8339285: test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames

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 thread).

Re: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows [v5]

On Wed, 4 Sep 2024 19:03:32 GMT, Brian Burkhalter wrote: >> Return the final path derived from the string returned by `canonicalize0()`. > > Brian Burkhalter has updated the pull request incrementally with one > additional commit since the last revision: > > 8003887: Use Assumptions.assumeTru

Re: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows [v5]

> Return the final path derived from the string returned by `canonicalize0()`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8003887: Use Assumptions.assumeTrue() and other and other cleanup - Changes: - all: htt

Re: RFR: 8003887: File.getCanonicalFile() does not resolve symlinks on MS Windows [v4]

On Wed, 4 Sep 2024 08:40:36 GMT, Alan Bateman wrote: >> Brian Burkhalter has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8003887: Test getCanonicalPath when the path contains links > > src/java.base/windows/native/libjava/WinNTFileSystem

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

On Wed, 4 Sep 2024 12:01:37 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: > > from @cl

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]

On Wed, 4 Sep 2024 11:54:48 GMT, Claes Redestad wrote: >> Let’s not add this, because normal logic should not pay the cost for >> abnormal logic > > Agreed in principle, but not sure the cost of this quick fail-fast sanity > test would be noticeable? If we add this, we should add this before t

Re: RFR: 8333446: Add tests for hierarchical container support [v9]

> Please review this PR which adds test support for systemd slices so that bugs > like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be > verified. The added test, `SystemdMemoryAwarenessTest` currently passes on > cgroups v1 and fails on cgroups v2 due to the way how > [JDK-82

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

On Wed, 4 Sep 2024 12:01:37 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: > > from @cl

Re: RFR: 8337408: Use GetTempPath2 API instead of GetTempPath [v2]

On Wed, 21 Aug 2024 09:07:21 GMT, Kevin Walls wrote: > Hi, > > From the linked doc: "When calling this function from a process running as > SYSTEM it will return the path C:\Windows\SystemTemp, which is inaccessible > to non-SYSTEM processes. For non-SYSTEM processes, GetTempPath2 will behave

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v3]

On Wed, 4 Sep 2024 16:45:38 GMT, Amit Kumar wrote: >> I looked into it, but couldn't find out. But I remove the `save_return_pc` & >> `restore_return_pc` and everything seems fine. So maybe we can remove it. > > Tier1 test are fine with/without "saving & restoring" return_pc; I found it: https

Integrated: 8339492: StackMapDecoder::writeFrames makes lots of allocations

On Tue, 3 Sep 2024 16:13:39 GMT, David M. Lloyd wrote: > Please review this change, which reduces the number of allocations in > `StackMapDecoder::writeFrames` by using a sorted array instead of a > `TreeMap` to sort and uniquify entries before writing. It also > adds a validation missed by th

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad wrote: >>> LGTM >>> >>> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per >>> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume >>> getting rid of the `TreeMap` and `Integer` key allocations more t

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v3]

On Wed, 4 Sep 2024 10:00:47 GMT, Martin Doerr wrote: >> Jorn Vernee has updated the pull request incrementally with one additional >> commit since the last revision: >> >> add RISC-V as target platform > > src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062: > >> 3060: StubCodeMark mar

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v3]

On Wed, 4 Sep 2024 16:45:04 GMT, Amit Kumar wrote: >> src/hotspot/cpu/s390/stubGenerator_s390.cpp line 3062: >> >>> 3060: StubCodeMark mark(this, "StubRoutines", >>> "upcall_stub_load_target"); >>> 3061: address start = __ pc(); >>> 3062: __ save_return_pc(); >> >> @offamitkumar: I

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 15:27:40 GMT, Chen Liang wrote: > > I'll see if I can get the benchmarks in > > `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there > > may be one or more of them which would reach into this code. > > Just checked; no benchmark is currently supplying a

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote: >> Please review this change, which reduces the number of allocations in >> `StackMapDecoder::writeFrames` by using a sorted array instead of a >> `TreeMap` to sort and uniquify entries before writing. It also >> adds a validation missed b

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote: >> Please review this change, which reduces the number of allocations in >> `StackMapDecoder::writeFrames` by using a sorted array instead of a >> `TreeMap` to sort and uniquify entries before writing. It also >> adds a validation missed b

Re: RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API [v2]

> 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

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 14:59:50 GMT, David M. Lloyd wrote: > I'll see if I can get the benchmarks in > `test/micro/org/openjdk/bench/jdk/classfile` working. It looks like there may > be one or more of them which would reach into this code. Just checked; no benchmark is currently supplying a manual

Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Thank you, Marko - it's an excellent catch! Indeed, we have a bug in a code that updates the left timeout. And yes, we should use nanoTime for measuring elapsed time. I will work on a fix for both issues and will try to create a test for the left timeout update scenario. - Aleksei _

Re: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v3]

On Wed, 4 Sep 2024 11:45:30 GMT, Severin Gehwolf wrote: >> fitzsim has updated the pull request incrementally with one additional >> commit since the last revision: >> >> BootClassPathZipFileTest: Switch to createClassBytes, createZip static >> functions > > Not an expert in this area, so ju

Re: RFR: 8336274: MutableBigInteger.leftShift(int) optimization [v6]

> This implementation of MutableBigInteger.leftShift(int) optimizes the current > version, avoiding unnecessary copy of the MutableBigInteger's value content > and performing the primitive shifting only in the original portion of the > value array rather than in the value yet extended with trail

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 14:18:09 GMT, Claes Redestad wrote: > > If so, then this amounts to a fairly minimal and direct code path, thus I > > approached this as being an "obvious" (as opposed to theoretical) > > improvement. > > I agree that it looks like the typical path is trivial, but I don't ha

Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

On 04/09/2024 15:02, Marko Bakšić wrote: Thank you Daniel. The part that was suspicious to me is ``` int timeoutLeft = pktTimeout; do {   ...   timeoutLeft = pktTimeout - ((int) (end - start)); } while (timeoutLeft > MIN_TIMEOUT); ``` Here, timeoutLeft is not iteratively decreased, but

Re: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v3]

On Wed, 4 Sep 2024 11:33:39 GMT, Severin Gehwolf wrote: >> fitzsim has updated the pull request incrementally with one additional >> commit since the last revision: >> >> BootClassPathZipFileTest: Switch to createClassBytes, createZip static >> functions > > test/hotspot/jtreg/runtime/BootCl

Re: RFR: 8339531: Improve performance of MemorySegment::mismatch

On Wed, 4 Sep 2024 09:09: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. src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 49: > 47: > 48: /

Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information

On Wed, 4 Sep 2024 12:22:49 GMT, Matthias Baesken wrote: > Hi , my guess is too that it is the second call. In case we want to go for a > loop, should we have a maximum number of retry operations like 10 or 100 ? > Another option might be to always make the buffer a little bigger (how much > c

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 14:12:06 GMT, David M. Lloyd wrote: >> LGTM >> >> AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per >> label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume >> getting rid of the `TreeMap` and `Integer` key allocations more than m

Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Hello Marko, core-libs-dev@openjdk.org is better suited for this kind of question. You can submit a bug using bugreport.java.com with all the details you have. Regards, Alexey On 2024-09-04 13:50, Marko Bakšić wrote: Hey there! Sorry for coming here with a technical question, but I would a

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 14:12:06 GMT, David M. Lloyd wrote: > If so, then this amounts to a fairly minimal and direct code path, thus I > approached this as being an "obvious" (as opposed to theoretical) improvement. I agree that it looks like the typical path is trivial, but I don't have the full

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 13:08:49 GMT, Claes Redestad wrote: > LGTM > > AFAICT before this we'd only call `DirectCodeBuilder::labelToBci` once per > label, but now we'll do so roughly `2*n*log(n) + n` times. I would assume > getting rid of the `TreeMap` and `Integer` key allocations more than makes

Re: Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Thank you Daniel. The part that was suspicious to me is ``` int timeoutLeft = pktTimeout; do {   ...   timeoutLeft = pktTimeout - ((int) (end - start)); } while (timeoutLeft > MIN_TIMEOUT); ``` Here, timeoutLeft is not iteratively decreased, but is always derived from `pktTimeout`. I ca

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

On Wed, 4 Sep 2024 12:01:37 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: > > from @cl

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v3]

On Wed, 4 Sep 2024 13:14: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 when the upcal

Integrated: 8325679: Optimize ArrayList subList sort

On Mon, 12 Feb 2024 22:52:51 GMT, Attila Szegedi wrote: > Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and will > thus fall back to slower default method of `List.sort()` instead of sorting a > range of the array in-place in its backing root `ArrayList`. > > This doesn

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

On Wed, 4 Sep 2024 12:01:37 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: > > from @cl

Re: Possible bug in jdk.naming.dns. I need guidance on how get someone smarter to look at it.

Hi Marko, This is not the proper list for this kind of question: I'm moving the discussion to core-libs-dev at openjdk.org. There's definitely a bug here: that code should use System.nanoTime() and not System.currentTimeMillis() since the latter is not guaranteed to be monotonic. It may not exp

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Wed, 4 Sep 2024 01:06:10 GMT, Shaojin Wen wrote: > It looks good, but can you provide the codeSize before and after the change? > For example, add the JVM startup parameters `-XX:+UnlockDiagnosticVMOptions > -XX:+PrintInlining` to find `writeFrames` and see if this PR will change from > les

Re: RFR: 8338123: Linker crash when building a downcall handle with many arguments in x64

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. Marked as reviewed by mcimadamore (Reviewer). -

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v3]

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

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v3]

> 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

Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Dear Daniel, Thank you for your insightful feedback on my approach. After carefully considering your points, I realize that I made a significant mistake in my initial implementation. I sincerely appreciate you bringing this to my attention. You were absolutely correct in pointing out the poten

Re: RFR: 8337753: Target class of upcall stub may be unloaded [v2]

> 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

Re: RFR: 8339492: StackMapDecoder::writeFrames makes lots of allocations [v2]

On Tue, 3 Sep 2024 17:33:37 GMT, David M. Lloyd wrote: >> Please review this change, which reduces the number of allocations in >> `StackMapDecoder::writeFrames` by using a sorted array instead of a >> `TreeMap` to sort and uniquify entries before writing. It also >> adds a validation missed b

RFR: 8338123: Linker crash when building a downcall handle with many arguments in x64

- 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

Re: RFR: 8337753: Target class of upcall stub may be unloaded

On Wed, 4 Sep 2024 11:58:49 GMT, Jorn Vernee wrote: > 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. - PR Review Comment: https://git.openjdk.org/jdk/pull/20479#discussion_r17437

Re: [External] : Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim, On 04/09/2024 12:50, 김민주 wrote: In the original approach, I intended for each thread to call |put|, confirm that it has entered the waiting state, and then allow the next thread to put the next sequence value and also enter the waiting state. This approach was designed to simulate a si

Integrated: 8339131: Remove rarely-used accessor methods from Opcode

On Wed, 28 Aug 2024 22:41:59 GMT, Chen Liang wrote: > In offline discussion, we agreed that current fields of `Opcode` violate data > oriented design to a large extent. The attributes not generic to all opcode > are removed. > > Up for preliminary review; needs to be reworked for #20737. This

Re: RFR: 8339131: Remove rarely-used accessor methods from Opcode [v2]

On Tue, 3 Sep 2024 23:22:28 GMT, Chen Liang wrote: >> In offline discussion, we agreed that current fields of `Opcode` violate >> data oriented design to a large extent. The attributes not generic to all >> opcode are removed. >> >> Up for preliminary review; needs to be reworked for #20737. >

Re: RFR: 8325679: Optimize ArrayList subList sort [v5]

On Wed, 4 Sep 2024 08:12:55 GMT, Attila Szegedi wrote: >> Somewhat surprisingly, `ArrayList$Sublist.sort()` is not specialized and >> will thus fall back to slower default method of `List.sort()` instead of >> sorting a range of the array in-place in its backing root `ArrayList`. >> >> This d

Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information

On Wed, 4 Sep 2024 12:05:09 GMT, Alan Bateman wrote: > > Unfortunately I don't know (but with this change and added JDK message text > > I would know next time). > > My guess is that it's the second call that is failing and the bug is that the > number of processes increased between the first

Re: RFR: 8339531: Improve performance of MemorySegment::mismatch

On Wed, 4 Sep 2024 09:09: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. src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 103: > 101: }

Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information

On Wed, 4 Sep 2024 11:39:57 GMT, Matthias Baesken wrote: > Unfortunately I don't know (but with this change and added JDK message text I > would know next time). My guess is that it's the second call that is failing and the bug is that the number of processes increased between the first and se

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v20]

> 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: from @cl4es 's suggestion - Changes: - all: https://git.o

Re: RFR: 8337753: Target class of upcall stub may be unloaded

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

Re: RFR: 8337753: Target class of upcall stub may be unloaded

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: ShouldNotReachHere(); >> >> How does `print_s

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]

On Wed, 4 Sep 2024 11:48:46 GMT, Shaojin Wen wrote: >> src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java >> line 165: >> >>> 163: int countNonZeroAscii = JLA.countNonZeroAscii(str); >>> 164: int utflen = strlen; >>> 165: if (countNonZeroAscii !=

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]

On Wed, 4 Sep 2024 10:59:33 GMT, Claes Redestad wrote: >> Shaojin Wen has updated the pull request incrementally with one additional >> commit since the last revision: >> >> optimize for utf16 > > src/java.base/share/classes/jdk/internal/classfile/impl/BufWriterImpl.java > line 165: > >> 16

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v19]

> 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: Unused local variable - Changes: - all: https://git.openj

Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Daniel, Thank you so much for your detailed insights in the previous email. I completely agree with your point that ensuring atomicity between the token retrieval (sequenceGenerator.getAndIncrement()) and placing it in the queue (queue.put()) is crucial to avoid issues such as thread interleavi

Re: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files [v3]

On Wed, 31 Jul 2024 21:54:15 GMT, fitzsim wrote: >> 8334048: -Xbootclasspath can not read some ZIP64 zip files > > fitzsim has updated the pull request incrementally with one additional commit > since the last revision: > > BootClassPathZipFileTest: Switch to createClassBytes, createZip stati

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v18]

> 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: Update src/java.base/share/classes/jdk/internal/access/JavaLangAccess.jav

Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information

On Wed, 4 Sep 2024 09:29:41 GMT, Alan Bateman wrote: > In your investigations, is it the first or second call to sysctl(3) that is > failing? Unfortunately I don't know (but with this change and added JDK message text I would know next time). - PR Comment: https://git.openjdk.org

Re: RFR: 8337753: Target class of upcall stub may be unloaded

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

Re: [POTENTIAL BUG] Potential FIFO violation in BlockingQueue under high contention and suggestion for fair mode in ArrayBlockingQueue and LinkedBlockingQueue

Hi Kim, When several threads compete to put items in a queue, regardless of queue locking strategies, nothing guarantees the order in which items will end up in the queue if the action of obtaining the next element and putting it in the queue is not atomic. This is because a thread can be preempt

Re: RFR: 8339290: Optimize ClassFile Utf8EntryImpl#writeTo [v17]

On Tue, 3 Sep 2024 16:27:58 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: > > optimize

Re: RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

On Tue, 3 Sep 2024 01:58:59 GMT, Chen Liang wrote: >> 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 te

Re: RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

On Tue, 3 Sep 2024 18:27:48 GMT, ExE Boss wrote: >> 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 test

Re: RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla wrote: > 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 tes

Re: RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla wrote: > 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 tes

RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

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 reflectively called w

Re: RFR: 8317356: Test ClassFile API if it deals with nulls correctly across the whole API

On Mon, 12 Aug 2024 17:23:15 GMT, Nizar Benalla wrote: > 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 tes

Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information

On Tue, 3 Sep 2024 14:09:23 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.getProcessPids0(Nat

Re: RFR: 8339531: Improve performance of MemorySegment::mismatch

On Wed, 4 Sep 2024 09:09: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. src/java.base/share/classes/jdk/internal/foreign/SegmentBulkOperations.java line 123: > 121: // Thi

Re: RFR: 8337753: Target class of upcall stub may be unloaded

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 when the upcall stu

RFR: 8339531: Improve performance of MemorySegment::mismatch

This PR proposes to improve the performance of `MemorySegment::mismatch` by using Java code rather than transitioning to native code. - Commit messages: - Remove temp methods - Clean up - Update comment - Merge branch 'master' into mismatch-performance2 - Create a separate class

Re: RFR: 8339487: ProcessHandleImpl native exceptions - include message text and last error information

On Wed, 4 Sep 2024 09:11:53 GMT, Matthias Baesken wrote: > The Apple sysctl manpage > https://developer.apple.com/library/archive/documentation/System/Conceptual/ManPages_iPhoneOS/man3/sysctl.3.html > documents a few ENOMEM related errors so the issue is probably related to > these. In your i

  1   2   >