On Thu, 23 Jan 2025 07:14:42 GMT, Adam Sotona wrote:
> JDK-8345486 moved
> java.lang.classfile.components.snippet-files.PackageSnippets to
> jdk.internal.classfile.components.snippet-files folder. However change of the
> package name declared in the snippet file was omitted.
>
> Please revie
On Thu, 23 Jan 2025 07:14:42 GMT, Adam Sotona wrote:
> JDK-8345486 moved
> java.lang.classfile.components.snippet-files.PackageSnippets to
> jdk.internal.classfile.components.snippet-files folder. However change of the
> package name declared in the snippet file was omitted.
>
> Please revie
On Fri, 24 Jan 2025 00:09:00 GMT, Brent Christian wrote:
>> Aleksey Shipilev has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - No instantiation for BufferCleaner, javadocs
>> - Remove hasReferencePendingList
>> - Revert test exclusio
A lot of jfr tests are very specific. Currently all of them are marked with jfr
keyword and excluded when VM flags are set.
It makes sense to mark them with @requires to be complaint with all
other openjdk tests.
The next step is to review tests and remove vm.flagless from tests that should
b
On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote:
>> Fix broken links in java.xml:
>>
>> Catalog: contacted Oasis. The standard page
>> (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF
>> version. That is what I'm using now, replacing the html pages. Not ideal,
>> but a
On Wed, 22 Jan 2025 18:55:10 GMT, Joe Wang wrote:
> Fix broken links in java.xml:
>
> Catalog: contacted Oasis. The standard page
> (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF
> version. That is what I'm using now, replacing the html pages. Not ideal, but
> at leas
On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
On 1/23/2025 2:35 PM, Remi Forax wrote:
Hello Jan,
what you are suggesting is not a backward compatible change.
There is a source compatibility impact, meaning that for some call
sites, the mapping of existing code using BigDecimal before and after
the addition of the overloaded method would
Hello,
On 1/23/2025 1:46 PM, Kevin Bourrillion wrote:
Hi,
Before addressing your request I want to try to just add a little
context as to what’s really going on (after which Joe will probably
correct me).
I'll augment Kevin's reply anyway :-)
You might know some or all of this, but it’s
On Thu, 23 Jan 2025 22:23:29 GMT, Justin Lu wrote:
>> src/java.base/share/classes/java/util/TimeZone.java line 659:
>>
>>> 657: * @since 25
>>> 658: */
>>> 659: public static synchronized Stream availableIDs(int
>>> rawOffset) {
>>
>> Why are these new methods synchronized? I thi
Hello Jan,
what you are suggesting is not a backward compatible change.
If we add BigDecimal,valueOf(float), then a program recompiled with the new JDK
may change its behavior,
you can think that the new behavior is more "correct" that the current one, but
changing the behavior of existing pr
On Thu, 23 Jan 2025 20:04:04 GMT, Chen Liang wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> include copyright bump for missed file in JDK-834836501
>
> src/java.base/share/classes/java/util/TimeZone.java line 659:
>
On Wed, 22 Jan 2025 03:28:00 GMT, Ioi Lam wrote:
> I reimplemented
> `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java
> code. This removes hacks in
> `SystemDictionary::resolve_with_circularity_detection()` to facilitate future
> clean-ups there that are planned by @c
On Wed, 22 Jan 2025 23:41:18 GMT, Coleen Phillimore wrote:
>> Ioi Lam 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 three additional commits
>
On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote:
> …String)
>
> This bug seems from the improper handling of package and class name
> initialization in `XSLTC` since there is a default value of `_packageName`
> with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
>
…String)
This bug seems from the improper handling of package and class name
initialization in `XSLTC` since there is a default value of `_packageName`
with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
before `setClassName`.
I've done the tire1 and tire2 tests. The t
On Thu, 28 Nov 2024 01:09:47 GMT, Zheng Feng wrote:
> …String)
>
> This bug seems from the improper handling of package and class name
> initialization in `XSLTC` since there is a default value of `_packageName`
> with `die.verwandlung`. This fix is just adjusting to call `setPackageName`
>
Hi,
Before addressing your request I want to try to just add a little context as to
what’s really going on (after which Joe will probably correct me). You might
know some or all of this, but it’s a refresher for everyone (including myself).
First, the value 0.1d is a “human-friendly” representa
Hi!
I’m currently working on a project that heavily relies on float values, and
we occasionally use BigDecimal for more precise mathematical operations.
However, I’ve noticed that the current BigDecimal constructor
implementation only supports double, which can lead to unintentional type
conversio
On Thu, 23 Jan 2025 19:50:04 GMT, Justin Lu wrote:
>> Please review this PR and CSR which add a pair of methods to
>> _java.util.TimeZone_ that return a stream of the available IDs. See the CSR
>> for the motivation.
>>
>> A number of existing tests are modified to use the new methods. See
>>
This is the last piece in the API documentation improvement of the Class-File
API.
This includes general documentation about transforms, models (and traversals),
options, constants, and CodeBuilder factories. In particular, this preserves
the package summary to avoid extra disruptions. See th
On Thu, 23 Jan 2025 19:13:22 GMT, Naoto Sato wrote:
>> Actually I'm wondering if we should specify these `rawOffset` methods with
>> an `@implNote` that states they are sorted.
>
> I'd rather not. If we did, users would wonder why no-arg return is not
> sorted, which might be a mere overlook (a
> Please review this PR and CSR which add a pair of methods to
> _java.util.TimeZone_ that return a stream of the available IDs. See the CSR
> for the motivation.
>
> A number of existing tests are modified to use the new methods. See
> _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which
This is a non-clean backport the java.lang.classfile.attribute documentation
improvements 973c630777d4075bc85c7ddc1eb02cc65904344d to JDK 24 , the release
where the API is finalized. Also backported a tier1 docs build hotfix
28e01e6559a79720d03355444a4e1c1fbf0b0373 for the broken links.
No rela
On Thu, 23 Jan 2025 19:02:32 GMT, Justin Lu wrote:
>> Noticed that too. There is also the argument that since these stream methods
>> are new, we can leave it un-sorted but we would have to specify the
>> deviation. Although I agree it is best to align for consistency.
>
> Actually I'm wonderin
On Thu, 23 Jan 2025 18:58:46 GMT, Justin Lu wrote:
>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 122:
>>
>>> 120: return zoneIds()
>>> 121: .filter(id -> getZoneInfo(id).getRawOffset() ==
>>> rawOffset)
>>> 122: .sorted(); // Sor
On Thu, 23 Jan 2025 17:41:35 GMT, Naoto Sato wrote:
>> Justin Lu has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> reflect Naoto's review
>
> src/java.base/share/classes/java/util/TimeZone.java line 652:
>
>> 650: *
>> 651: * @p
> Please review this PR and CSR which add a pair of methods to
> _java.util.TimeZone_ that return a stream of the available IDs. See the CSR
> for the motivation.
>
> A number of existing tests are modified to use the new methods. See
> _test/jdk/java/util/TimeZone/AvailableIDsTest.java_ which
On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote:
>> Fix broken links in java.xml:
>>
>> Catalog: contacted Oasis. The standard page
>> (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF
>> version. That is what I'm using now, replacing the html pages. Not ideal,
>> but a
> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>
> For performance, signaling flags (bottom 6 bits) are set by default in MXCSR.
> This PR fixes the Xcheck:jni comparison that is producing these copious
> warnings:
>
> OpenJDK 64-Bit Server VM warning: MXCSR changed by native JNI
On Thu, 23 Jan 2025 18:23:01 GMT, Volodymyr Paprotski
wrote:
>> (Also see `8319429: Resetting MXCSR flags degrades ecore`)
>>
>> For performance, signaling flags (bottom 6 bits) are set by default in
>> MXCSR. This PR fixes the Xcheck:jni comparison that is producing these
>> copious warning
On Thu, 23 Jan 2025 02:49:49 GMT, Justin Lu wrote:
> Please review this PR and CSR which add a pair of methods to
> _java.util.TimeZone_ that return a stream of the available IDs. See the CSR
> for the motivation.
>
> A number of existing tests are modified to use the new methods. See
> _test
On Thu, 23 Jan 2025 15:21:24 GMT, Matthias Ernst wrote:
> losing
`ofAuto` works fine, at least for now. I was mostly brainstorming aloud on how
to get back to deterministic deallocation.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/23142#discussion_r1927475963
On Thu, 23 Jan 2025 05:42:33 GMT, Liam Miller-Cushon wrote:
> This change fixes an incorrect call to `printf` for a failure message in
> `CLDRDisplayNamesTest`.
Marked as reviewed by naoto (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23252#pullrequestreview-2570533968
> @TobiHartmann There are still some unanswered questions I have, but
> committing this since we need to work around vacation schedules.
>
> **This in fact happens on both Windows _AND_ Linux.** However, _only_ on
> Windows there is a crash. This fix fixes the crash but I don't understand
> en
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Thu, 23 Jan 2025 17:13:37 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Thu, 23 Jan 2025 17:23:48 GMT, Matthias Ernst wrote:
> Need to strategically place yields or interrupt the competitors.
Maybe the number of iterations could be capped?
-
PR Comment: https://git.openjdk.org/jdk/pull/23142#issuecomment-2610515954
On Thu, 23 Jan 2025 17:13:37 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Thu, 23 Jan 2025 05:42:33 GMT, Liam Miller-Cushon wrote:
> This change fixes an incorrect call to `printf` for a failure message in
> `CLDRDisplayNamesTest`.
This pull request has now been integrated.
Changeset: d9d2e19f
Author:Liam Miller-Cushon
URL:
https://git.openjdk.org/jdk
On Thu, 23 Jan 2025 17:14:56 GMT, Jorn Vernee wrote:
> test is timing out
I think it's the stress test, the starting Thread sleeps and never gets
rescheduled because it's starved out by the others. I can repro. Need to
strategically place yields or interrupt the competitors.
-
PR
On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote:
>> Fix broken links in java.xml:
>>
>> Catalog: contacted Oasis. The standard page
>> (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF
>> version. That is what I'm using now, replacing the html pages. Not ideal,
>> but a
On Thu, 23 Jan 2025 08:51:38 GMT, Aleksey Shipilev wrote:
>> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
>> implementation. That implementation carries a doubly-linked list, and so
>> makes DBB suffer from the same issue fixed for generic
>> `java.lang.ref.Cleaner` users w
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Thu, 23 Jan 2025 08:33:23 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote:
> `Reference.waitForReferenceProcessing` is in internal API, which should go
> away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There
> is single use of that internal API in the tests, the last use of which was
> re
On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote:
> `Reference.waitForReferenceProcessing` is in internal API, which should go
> away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There
> is single use of that internal API in the tests, the last use of which was
> re
On Thu, 23 Jan 2025 02:04:33 GMT, Ioi Lam wrote:
>> I reimplemented
>> `SystemDictionaryShared::lookup_super_for_unregistered_class()` with Java
>> code. This removes hacks in
>> `SystemDictionary::resolve_with_circularity_detection()` to facilitate
>> future clean-ups there that are planned
On Thu, 23 Jan 2025 14:49:28 GMT, Aleksey Shipilev wrote:
> I think I need another review for integration?
Alan's review should be sufficient I think. The bug should have a `noreg-self`
label.
-
PR Comment: https://git.openjdk.org/jdk/pull/23239#issuecomment-2610341728
On Wed, 22 Jan 2025 20:35:22 GMT, Phil Race wrote:
>> Only the `writeExternal` method is required to have a `@serialData` tag in
>> order to keep javadoc running with `-serialwarn` option from complaining. I
>> guess the thinking is that the `readExternal` logic can be derived from that.
>>
>>
On Thu, 23 Jan 2025 07:14:42 GMT, Adam Sotona wrote:
> JDK-8345486 moved
> java.lang.classfile.components.snippet-files.PackageSnippets to
> jdk.internal.classfile.components.snippet-files folder. However change of the
> package name declared in the snippet file was omitted.
>
> Please revie
On Thu, 23 Jan 2025 15:23:37 GMT, Kevin Walls wrote:
> java.util.logging.LoggingMXBean and
> java.util.logging.LogManager::getLoggingMXBean are deprecated since
> JDK-8139982 in JDK 9.
>
> These deprecations should be uprated to state they are for future removal.
>
> java.util.logging.Logging
java.util.logging.LoggingMXBean and
java.util.logging.LogManager::getLoggingMXBean are deprecated since JDK-8139982
in JDK 9.
These deprecations should be uprated to state they are for future removal.
java.util.logging.Logging (implements LoggingMXBean) should also be deprecated
for removal.
On Thu, 23 Jan 2025 15:14:30 GMT, Maurizio Cimadamore
wrote:
>> A simpler (maybe interim) solution: if the requesting thread is not virtual,
>> use the cache (and use a confined arena). Otherwise use a brand new confined
>> arena.
>
> Yet another option would be to use a confined or shared are
On Thu, 23 Jan 2025 14:54:55 GMT, Maurizio Cimadamore
wrote:
>> alternatively - we could have some kind of internal "forceClose" API which
>> doesn't check the owner thread. ~Some care is probably needed as the access
>> is now on a different thread, so we'll need to make sure that some volati
On Thu, 23 Jan 2025 14:35:29 GMT, Maurizio Cimadamore
wrote:
>> If this is really the case, I agree that there doesn't seem to be an
>> alternative to use `ofAuto`. In which case you don't really need a
>> TerminatingThreadLocal -- a CarrierThreadLocal is just fine (given we don't
>> really h
On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote:
> `Reference.waitForReferenceProcessing` is in internal API, which should go
> away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There
> is single use of that internal API in the tests, the last use of which was
> re
On Thu, 23 Jan 2025 14:32:22 GMT, Maurizio Cimadamore
wrote:
>> Exactly. initialValue happens on-demand, not upfront, i.e. in the very
>> moment the VT calls get().
>> Whereas terminate happens as the last action of the CT.
>
> If this is really the case, I agree that there doesn't seem to be a
On Thu, 23 Jan 2025 14:28:57 GMT, Matthias Ernst wrote:
>>> Ah no, the allocate fails of course:
>>>
>>> ```
>>> java.lang.WrongThreadException: Attempted access outside owning thread
>>> at
>>> java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322)
>>>
On Thu, 23 Jan 2025 14:26:23 GMT, Maurizio Cimadamore
wrote:
>> Ah no, the allocate fails of course:
>>
>> java.lang.WrongThreadException: Attempted access outside owning thread
>> at
>> java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322)
>> at
>
On Thu, 23 Jan 2025 13:07:03 GMT, Matthias Ernst wrote:
> Ah no, the allocate fails of course:
>
> ```
> java.lang.WrongThreadException: Attempted access outside owning thread
> at
> java.base/jdk.internal.foreign.MemorySessionImpl.wrongThread(MemorySessionImpl.java:322)
> at
> jav
On Thu, 23 Jan 2025 12:53:08 GMT, Matthias Ernst wrote:
> We could, in the sense that an allocation in a lower stack frame seems
> suspicious, but technically it is completely legal. The frame has been
> allocated and is sliced to the requested size, and is guaranteed as long as
> the Frame's
On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote:
> Add additional diagnostics to macOS failure handler to assist with diagnosing
> MCast test failures
This pull request has now been integrated.
Changeset: 5cc690d3
Author:Serhiy Sachkov
Committer: Mark Sheppard
URL:
https://g
On Thu, 23 Jan 2025 02:47:00 GMT, Justin Lu wrote:
>> How about I revert the most recent commit and have this PR simply deliver
>> the change to provide the stream of currencies. I'll file another issue to
>> improve `available` to use stable values when that is available. Does that
>> sound f
On Wed, 22 Jan 2025 18:39:47 GMT, Justin Lu wrote:
>> Please review this PR which contains the l10n translations for between RDP1
>> and RDP2 for the JDK24 stabilization branch.
>>
>> Note that these translations are only associated with changes made to the
>> stabilization branch. This PR wil
On Thu, 23 Jan 2025 12:37:16 GMT, Maurizio Cimadamore
wrote:
>> Matthias Ernst has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - test deep linker stack
>> - Merge remote-tracking branch 'origin/mernst/cache-segments' into
>> mernst/c
On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote:
> Add additional diagnostics to macOS failure handler to assist with diagnosing
> MCast test failures
@serhiysachkov
Your change (at version 3a7f43ef409e09bbf818a9f43dee1f544538b104) is now ready
to be sponsored by a Committer.
-
On Thu, 23 Jan 2025 12:59:53 GMT, Matthias Ernst wrote:
>>> the shared memory segment is confined on the carrier thread
>>
>> But is it? When the CarrierThreadLocal is initialized, we may be executing
>> in a VT and Arena.ofConfined will confine to it. We'd need something like an
>> Arena.ofCa
On Thu, 23 Jan 2025 12:50:41 GMT, Matthias Ernst wrote:
>> So:
>> * the shared memory segment is confined on the carrier thread
>> * allocation requests need to reinterpret segment slices to the arena (which
>> is associated with the requesting thread, not the carrier)
>> * my understanding is t
On Thu, 23 Jan 2025 12:27:53 GMT, Maurizio Cimadamore
wrote:
> the shared memory segment is confined on the carrier thread
But is it? When the CarrierThreadLocal is initialized, we may be executing in a
VT and Arena.ofConfined will confine to it. We'd need something like an
Arena.ofCarrierCon
On Wed, 22 Jan 2025 12:38:25 GMT, Matthias Ernst wrote:
>> Right. Using SlicingAllocator now.
>>
>> Which brings up one question about alignment of the stack frames. When the
>> linker asks for a buffer, it also has an alignment requirement. Do we
>> guarantee anything about the alignment of A
On Thu, 23 Jan 2025 08:33:23 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Thu, 23 Jan 2025 08:33:23 GMT, Matthias Ernst wrote:
>> Certain signatures for foreign function calls (e.g. HVA return by value)
>> require allocation of an intermediate buffer to adapt the FFM's to the
>> native stub's calling convention. In the current implementation, this buffer
>> is ma
On Wed, 22 Jan 2025 12:27:10 GMT, Matthias Ernst wrote:
>> src/java.base/share/classes/jdk/internal/foreign/abi/BufferStack.java line
>> 52:
>>
>>> 50: scope.close();
>>> 51: offset = parentOffset;
>>> 52: lock.unlock();
>>
>> I believe you could have mismat
On Wed, 22 Jan 2025 12:26:45 GMT, Matthias Ernst wrote:
>> Isn't the problem access? E.g. a virtual thread `A` running on our carrier
>> thread might create the confined arena, binding it to _virtual_ thread `A`,
>> and then another virtual thread `B` comes along one the same carrier thread,
>
Having had the opportunity to use ScopedValue to replace ThreadLocal, it
was suggested I might provide some feedback here.
Background: I'm maintaining an OpenJDK fork that retains SM, I merge
weekly from upstream, this isn't for untrusted code, it's just ensuring
permissions are only granted t
On Thu, 23 Jan 2025 10:38:50 GMT, serhiysachkov wrote:
> Add additional diagnostics to macOS failure handler to assist with diagnosing
> MCast test failures
Marked as reviewed by dfuchs (Reviewer).
Looks good to me. Good to have these additional diagnostics.
-
PR Review: https://
On Thu, 23 Jan 2025 00:46:07 GMT, Joe Wang wrote:
>> Fix broken links in java.xml:
>>
>> Catalog: contacted Oasis. The standard page
>> (https://www.oasis-open.org/standard/xmlcatalogs/) now links to the PDF
>> version. That is what I'm using now, replacing the html pages. Not ideal,
>> but a
On Thu, 23 Jan 2025 10:54:23 GMT, Alan Bateman wrote:
> So the test wasn't actually calling Reference::waitForReferenceProcessing, do
> I have this right? In that case, this PR looks fine.
Yup. The last use of `Reference::waitForReferenceProcessing` was removed by
[JDK-8080225](https://bugs.op
On Thu, 23 Jan 2025 10:54:54 GMT, Hamlin Li wrote:
>> @Hamlin-Li , Class types are passed as constant oop, this check is added for
>> argument validation.
>
> Thanks!
> Seems it could be an assert instead? Or maybe I could have misunderstood your
> above explanation.
Hi @Hamlin-Li, We intend t
On Thu, 23 Jan 2025 08:32:47 GMT, Jatin Bhateja wrote:
>> src/hotspot/share/opto/library_call.cpp line 8670:
>>
>>> 8668:
>>> 8669: const TypeInstPtr* box_type = _gvn.type(argument(0))->isa_instptr();
>>> 8670: if (box_type == nullptr || box_type->const_oop() == nullptr) {
>>
>> Hi, this i
On Wed, 22 Jan 2025 16:59:04 GMT, Aleksey Shipilev wrote:
> `Reference.waitForReferenceProcessing` is in internal API, which should go
> away with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332). There
> is single use of that internal API in the tests, the last use of which was
> re
On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection
Add additional diagnostics to macOS failure handler to assist with diagnosing
MCast test failures
-
Commit messages:
- 8347994: fixing trailing whitespace
- 8347994: Add additional diagnostics to macOS failure handler to assist with
diagnosing MCast test failures
Changes: https:/
On Wed, 22 Jan 2025 08:30:16 GMT, Richard Reingruber wrote:
> Hi all,
>
> I would like to backport the test-fix from commit
> [15d6469e](https://github.com/openjdk/jdk/commit/15d6469e8da635364c0ba83e425fd149c2d69495)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> The back
> We were running into this error :
> sun/tools/jhsdb/HeapDumpTestWithActiveProcess.java on Linux aarch64, jdk25
>
> stderr: [java.lang.RuntimeException: Unable to deduce type of thread from
> address 0x34144e30 (expected type JavaThread, CompilerThread,
> MonitorDeflationThread, AttachL
On Wed, 22 Jan 2025 20:05:25 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> (c)
>
> test/jdk/java/foreign/TestBufferStack.java line 122:
>
>> 120: thread -> Assert.assertTrue(th
On Wed, 22 Jan 2025 23:44:02 GMT, Brent Christian wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Alan's review
>
> src/java.base/share/classes/java/nio/BufferCleaner.java line 31:
>
>> 29: import java.lang.re
> DirectByteBuffers are still using old `jdk.internal.ref.Cleaner`
> implementation. That implementation carries a doubly-linked list, and so
> makes DBB suffer from the same issue fixed for generic
> `java.lang.ref.Cleaner` users with
> [JDK-8343704](https://bugs.openjdk.org/browse/JDK-8343704
On Wed, 22 Jan 2025 20:35:49 GMT, Brent Christian wrote:
>> Aleksey Shipilev has updated the pull request incrementally with three
>> additional commits since the last revision:
>>
>> - No instantiation for BufferCleaner, javadocs
>> - Remove hasReferencePendingList
>> - Revert test exclusio
On Mon, 20 Jan 2025 12:12:20 GMT, Alan Bateman wrote:
>> Extend the support for optional dependences to allow for a service to be
>> optional. The post-resolution consistency check specified by
>> `Configuration.resolve` is relaxed to allow for the possibility that the
>> service from a module
On Thu, 23 Jan 2025 08:14:13 GMT, Hamlin Li wrote:
>> Jatin Bhateja has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Review suggestions incorporated.
>
> src/hotspot/share/opto/library_call.cpp line 8670:
>
>> 8668:
>> 8669: const Typ
On Wed, 22 Jan 2025 17:06:22 GMT, Jorn Vernee wrote:
>> Matthias Ernst has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> an attempt at a stress test
>
> test/jdk/java/foreign/TestBufferStack.java line 9:
>
>> 7: * published by the Free S
> Certain signatures for foreign function calls (e.g. HVA return by value)
> require allocation of an intermediate buffer to adapt the FFM's to the native
> stub's calling convention. In the current implementation, this buffer is
> malloced and freed on every FFM invocation, a non-negligible ove
On Thu, 23 Jan 2025 05:42:33 GMT, Liam Miller-Cushon wrote:
> This change fixes an incorrect call to `printf` for a failure message in
> `CLDRDisplayNamesTest`.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23252#pullrequestreview-2569169006
On Tue, 21 Jan 2025 13:03:45 GMT, Johny Jose wrote:
> Changes to Update Timezone Data to 2025a
This pull request has now been integrated.
Changeset: caa3c78f
Author:Johny Jose
Committer: Sean Coffey
URL:
https://git.openjdk.org/jdk/commit/caa3c78f7837b1f561740184bd8f9cb671c467eb
St
On Fri, 17 Jan 2025 16:02:55 GMT, Jatin Bhateja wrote:
>> Hi All,
>>
>> This patch adds C2 compiler support for various Float16 operations added by
>> [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>>
>> Following is the summary of changes included with this patch:-
>>
>> 1. Detection
98 matches
Mail list logo
