On Sat, 12 Jul 2025 17:36:54 GMT, Matthias Baesken wrote:
>> The following is reported when building with the gcc static analyzer
>> (-fanalyzer) :
>>
>>
>> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak
>> of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
>> 244 |
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 12:45:55 GMT, Matthias Baesken wrote:
> The following is reported when building with the gcc static analyzer
> (-fanalyzer) :
>
>
> /jdk/src/java.base/unix/native/libjava/java_props_md.c:244:17: warning: leak
> of 'temp' [CWE-401] [-Wanalyzer-malloc-leak]
> 244 | return
On Thu, 10 Jul 2025 23:40:15 GMT, Chen Liang wrote:
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the
On Wed, 2 Jul 2025 11:00:44 GMT, Manuel Hässig wrote:
> When a check in `CommandLineOptionTest` fails, the `AssertionError` message
> contains the expected value, but not the observed value. To reduce the amount
> of digging in the logs we have to do when analyzing a failure, this PR adds
> th
SonarCloud points out that ThreadLock class introduced by
[JDK-8357650](https://bugs.openjdk.org/browse/JDK-8357650) can be turned into
static nested class. I don't think this shows any real bug yet, as unreferenced
enclosing class reference gets nowhere. But it would be nice to be extra crisp
On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev wrote:
>> SonarCloud complains that since
>> [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using
>> `Boolean` boxes in `ReverseOrderListView`. This change `boolean` ->
>> `Boolean` was made
On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote:
> SonarCloud complains that since
> [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using
> `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean`
> was made in [JDK
On Mon, 2 Jun 2025 13:26:36 GMT, Aleksey Shipilev wrote:
>> SonarCloud complains that since
>> [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using
>> `Boolean` boxes in `ReverseOrderListView`. This change `boolean` ->
>> `Boolean` was made
On Mon, 26 May 2025 17:08:45 GMT, Aleksey Shipilev wrote:
> SonarCloud complains that since
> [JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are using
> `Boolean` boxes in `ReverseOrderListView`. This change `boolean` -> `Boolean`
> was made in [JDK
t;
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/util`
Aleksey Shipilev 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
On Fri, 30 May 2025 12:16:15 GMT, Viktor Klang wrote:
> Bumping the (synthetic) delays to 100 seconds to ensure that they don't run
> prior to shutdown being finished.
Looks fine, thanks.
-
Marked as reviewed by shade (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/25548#
On Tue, 27 May 2025 11:33:28 GMT, Chen Liang wrote:
> If we do use byte, please add constant static final fields instead of magic
> that requires navigation from pass site to fields.
My initial version did this, and IMO it was worse off:
https://github.com/openjdk/jdk/pull/25456/commits/06d3f
On Mon, 26 May 2025 16:37:01 GMT, Aleksey Shipilev wrote:
> SonarCloud complains `ST_NEW` constant is not used. Looks to me the
> constructor implicitly relies on default value for `state`. It would be
> cleaner to initialize it explicitly
>
> Additional testing:
> - [x] L
On Mon, 26 May 2025 17:17:30 GMT, Aleksey Shipilev wrote:
>> SonarCloud complains `ST_NEW` constant is not used. Looks to me the
>> constructor implicitly relies on default value for `state`. It would be
>> cleaner to initialize it explicitly
>>
>> Additional t
On Tue, 27 May 2025 07:45:35 GMT, Alan Bateman wrote:
> Does SonarCloud scan source code or class files? I'm wondering if there is
> anything to feedback to them on this report.
I think both. But as I said, I misunderstood the report: it tells me we are
using a boxed `Boolean`, likely unnecess
On Mon, 26 May 2025 19:01:35 GMT, Chen Liang wrote:
> How is this an allocation? I examined `javap -c -p -v
> java.util.ReverseOrderListView` and confirmed this compiles to
> `Boolean.valueOf` in class files, which involves no new allocation.
Yeah, I brain-fogged a little here. Still, it makes
> SonarCloud complains `ST_NEW` constant is not used. Looks to me the
> constructor implicitly relies on default value for `state`. It would be
> cleaner to initialize it explicitly
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/util/concurrent`
Al
On Mon, 26 May 2025 16:46:49 GMT, Alan Bateman wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Move to the end
>
> src/java.base/share/classes/java/util/concurrent/Structure
SonarCloud complains that since
[JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) we are allocating
and using `Boolean` boxes in `ReverseOrderListView`. This change `boolean` ->
`Boolean` was made in
[JDK-8356080](https://bugs.openjdk.org/browse/JDK-8356080) to allow `@Stable`
folding
SonarCloud complains `ST_NEW` constant is not used. Looks to me the constructor
implicitly relies on default value for `state`. It would be cleaner to
initialize it explicitly
Additional testing:
- [x] Linux x86_64 server fastdebug, `java/util/concurrent`
-
Commit messages:
- Fix
On Tue, 18 Feb 2025 14:33:16 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
On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote:
> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the
> suggestion to use VFORK in jspawnhelper misbehaves. But
> [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK!
> So
On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote:
> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the
> suggestion to use VFORK in jspawnhelper misbehaves. But
> [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK!
> So
On Wed, 21 May 2025 08:34:21 GMT, Aleksey Shipilev wrote:
> In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the
> suggestion to use VFORK in jspawnhelper misbehaves. But
> [JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK!
> So
In [JDK-8352533](https://bugs.openjdk.org/browse/JDK-8352533), we print the
suggestion to use VFORK in jspawnhelper misbehaves. But
[JDK-8357179](https://bugs.openjdk.org/browse/JDK-8357179) deprecated VFORK! So
the warning message should actually suggest using FORK. This seems to be in
line wi
On Mon, 19 May 2025 16:59:06 GMT, Thomas Stuefe wrote:
>> For the ratio behind this please see the companion CSR:
>> https://bugs.openjdk.org/browse/JDK-8357180.
>>
>> We plan to deprecate this in JDK 25 and to remove it in JDK 26.
>>
>> This patch just writes a deprecation message to stderr:
On Fri, 21 Mar 2025 10:00:26 GMT, Aleksey Shipilev wrote:
> When jspawnhelper fails for whatever reason, but more prominently due to
> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
> the errors into stdout, but not to the relevant `IOException`. S
On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOExce
On Tue, 13 May 2025 10:30:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOExce
On Wed, 30 Apr 2025 16:06:23 GMT, Roger Riggs wrote:
>> Aleksey Shipilev 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 conta
On Tue, 6 May 2025 11:23:32 GMT, Thomas Stuefe wrote:
>> Aleksey Shipilev 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 conta
bout the actual message :)
>
> Additional testing:
> - [x] Ad-hoc experiments with breaking jspawnhelper
> - [x] macos-aarch64-server-fastdebug, `java/lang/Process
> java/lang/ProcessBuilder`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge o
On Tue, 6 May 2025 10:56:54 GMT, Thomas Stuefe wrote:
>> Aleksey Shipilev 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 conta
On Tue, 6 May 2025 10:51:14 GMT, Thomas Stuefe wrote:
>> Aleksey Shipilev 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 conta
On Wed, 30 Apr 2025 16:11:14 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOExce
On Wed, 30 Apr 2025 14:50:03 GMT, Roger Riggs wrote:
> Please add the test number 8352533 to the @bug tag in Basic.java.
Thanks, added!
-
PR Comment: https://git.openjdk.org/jdk/pull/24149#issuecomment-2842494196
bout the actual message :)
>
> Additional testing:
> - [x] Ad-hoc experiments with breaking jspawnhelper
> - [x] macos-aarch64-server-fastdebug, `java/lang/Process
> java/lang/ProcessBuilder`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge o
On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOExce
On Fri, 25 Apr 2025 14:49:37 GMT, Aleksey Shipilev wrote:
> CDS cannot handle large number of classes, because `ClassLoader` data
> structures get too large for CDS archival. The new test captures such an
> occasion. We do `clear()`-s, but that is not enough to trim the backing
>
On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev wrote:
>> CDS cannot handle large number of classes, because `ClassLoader` data
>> structures get too large for CDS archival. The new test captures such an
>> occasion. We do `clear()`-s, but that is not enough to trim the ba
On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev wrote:
>> CDS cannot handle large number of classes, because `ClassLoader` data
>> structures get too large for CDS archival. The new test captures such an
>> occasion. We do `clear()`-s, but that is not enough to trim the ba
On Mon, 28 Apr 2025 09:20:38 GMT, Aleksey Shipilev wrote:
>> CDS cannot handle large number of classes, because `ClassLoader` data
>> structures get too large for CDS archival. The new test captures such an
>> occasion. We do `clear()`-s, but that is not enough to trim the ba
On Fri, 25 Apr 2025 20:54:21 GMT, John R Rose wrote:
>> Aleksey Shipilev 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 contai
On Sun, 27 Apr 2025 20:32:24 GMT, Andrey Turbanov wrote:
>> Aleksey Shipilev 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 contai
his allows us to stay fully in Java, and makes the patch fairly
> straightforward.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, new test reliably fails without the
> fix, passes with it
> - [x] Linux x86_64 server fastdebug, `runtime/cds`
Aleksey Shipilev has
On Thu, 24 Apr 2025 17:31:50 GMT, Severin Gehwolf wrote:
> Please review this fix to
> [JDK-8353185](https://bugs.openjdk.org/browse/JDK-8353185). The reading logic
> for the config file would erroneously use `scanner.nextLine()` when the
> current line to be added is in `line`. `line` is not
On Mon, 14 Apr 2025 15:46:54 GMT, Jaikiran Pai wrote:
> It then means that the other field will never move out of its initial value
> and thus will never be considered "stable".
For all non-zero hashcodes, it matters that `hash` would be constant-foldable,
which means `if (h == 0 && !hashIsZe
On Mon, 14 Apr 2025 14:47:59 GMT, Per Minborg wrote:
> This PR proposes to add the `@Stable` annotation to `j.l.String.hash` and
> `j.l.String.hashIsZero`. This means the VM can trust these fields to never
> change which enables constant folding optimizations.
>
> This PR is tested in tier1, t
On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOExce
On Fri, 11 Apr 2025 09:09:05 GMT, Kim Barrett wrote:
>> On a second thought, I think we should do this shift before this PR, so that
>> it is cleanly backportable. This bug messes with concurrent GC invariants,
>> so it would be nice to fix it in current LTSes.
>
> As far as I can tell, intrins
On Fri, 11 Apr 2025 08:03:07 GMT, Aleksey Shipilev wrote:
>> You need to use intrinsic predicates to add runtime check for receiver. See:
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/library_call.cpp#L167
>
> I think it would be "easier" to sh
On Thu, 10 Apr 2025 18:26:39 GMT, Vladimir Kozlov wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 357:
>>
>>> 355: @IntrinsicCandidate
>>> 356: public T get() {
>>> 357: return get0();
>>
>> I am looking at this now and wondering how current intrinsics ma
On Thu, 10 Apr 2025 07:25:47 GMT, Thomas Schatzl wrote:
> I fixed this for now, but it will be broken again in just a bit with
> Aleksey's ongoing removal of x86 32 bit platform efforts.
I think all x86 cleanups related to GC and adjacent code have landed in
mainline now. So I expect no more m
On Wed, 2 Apr 2025 18:33:16 GMT, Kim Barrett wrote:
>> Please review this change which adds a native method providing the
>> implementation of Reference::get. Referece::get is an intrinsic candidate,
>> so
>> this native method implementation is only used when the intrinsic is not.
>>
>> Curre
When jspawnhelper fails for whatever reason, but more prominently due to
[JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report the
errors into stdout, but not to the relevant `IOException`. So, if the
application is configured to only capture the exception logs (e.g. through
On Wed, 26 Mar 2025 17:31:47 GMT, Aleksey Shipilev wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOExce
bout the actual message :)
>
> Additional testing:
> - [x] Ad-hoc experiments with breaking jspawnhelper
> - [x] macos-aarch64-server-fastdebug, `java/lang/Process
> java/lang/ProcessBuilder`
Aleksey Shipilev has updated the pull request incrementally with one additional
com
On Wed, 26 Mar 2025 19:28:24 GMT, Jiangli Zhou wrote:
>> Please review following changes, thanks.
>>
>> - Add `static` to the vm_info for static JDK. The `-version` output now
>> contains `static` on static JDK, e.g.:
>>
>>
>> $ static-jdk/bin/java -version
>> openjdk version "25-internal" 20
bout the actual message :)
>
> Additional testing:
> - [x] Ad-hoc experiments with breaking jspawnhelper
> - [x] macos-aarch64-server-fastdebug, `java/lang/Process
> java/lang/ProcessBuilder`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge o
On Tue, 25 Mar 2025 23:58:36 GMT, Volker Simonis wrote:
>> Aleksey Shipilev 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 contain
On Thu, 20 Mar 2025 11:00:01 GMT, Severin Gehwolf wrote:
>> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 160:
>>
>>> 158:
>>> 159: if (strcmp(argv[1], VERSION_STRING) != 0) {
>>> 160: fprintf(stdout, "Incorrect Java version: %s\n", argv[1]);
>>
>> Don't you want to ke
On Tue, 25 Mar 2025 19:35:36 GMT, Dan Lutker wrote:
>> When jspawnhelper fails for whatever reason, but more prominently due to
>> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
>> the errors into stdout, but not to the relevant `IOException`. So, if the
>> applicat
On Fri, 21 Mar 2025 10:00:26 GMT, Aleksey Shipilev wrote:
> When jspawnhelper fails for whatever reason, but more prominently due to
> [JDK-8325621](https://bugs.openjdk.org/browse/JDK-8325621), it will report
> the errors into stdout, but not to the relevant `IOException`. S
On Thu, 20 Mar 2025 09:52:02 GMT, Aleksey Shipilev wrote:
> See the bug for rationale.
>
> This goal for this improvement is to be easily backportable, so we can catch
> up with update releases. As such, it does a few borderline-trivial changes,
> and _does not_ change t
On Thu, 20 Mar 2025 11:09:34 GMT, Alan Bateman wrote:
> In any case, I don't think we should change main line as it currently targets
> JDK 25 so won't GA for 6 months. Maybe there is a case to re-examine in the
> update releases where the jspawnhelper checks were back ported but I think we
>
On Thu, 20 Mar 2025 10:09:31 GMT, Alan Bateman wrote:
> Something is very broken if the JDK is being overridden while in use.
Yes, that was the original thinking for jspawnhelper version checks.
> So I don't think I agree that relaxing the check is the right thing to do,
> it's not fixing the
See the bug for rationale.
This goal for this improvement is to be easily backportable, so we can catch up
with update releases. As such, it does a few borderline-trivial changes, and
_does not_ change the jspawnhelper protocol. So the overwrite of `jspawnhelper`
with this new version would be
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
For completeness/reference, this is my JDK frankensteining script that is used
for producing buil
On Fri, 14 Mar 2025 17:57:31 GMT, Magnus Ihse Bursie wrote:
> No, it doesn't -- only libjvm.so. .jsa files complicate the situation. Hm.
Aha. Importing CDS archives without regenerating them is futile, IIRC: they
would never load properly, CDS would get disabled, and we would just carry dead
w
On Fri, 14 Mar 2025 15:49:44 GMT, Magnus Ihse Bursie wrote:
> We should allow pre-built JVMs to be included in a build, so they are just
> copied into place, and the jvm.cfg file properly updated.
This change copies `libjvm.so` _and_ sibling `.jsa` files, right?
If so, then one thing is missin
On Fri, 7 Mar 2025 23:17:53 GMT, Kim Barrett wrote:
> Please review this revision of a previously puzzling comment intending to
> provide the rationale for a bit of non-obvious code.
Marked as reviewed by shade (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/23952#pullreq
On Tue, 18 Feb 2025 11:01:51 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert waitForReferenceProcessing removals, see JDK-8305186
>
> There are several ch
need another way to check progress that involves checking if
> cleaner has acted.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/nio java/io`
> - [x] Linux AArch64 server fastdebug, `java/nio java/io`
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux
On Tue, 18 Feb 2025 10:54:13 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Revert waitForReferenceProcessing removals, see JDK-8305186
>
> src/java.base/share/c
need another way to check progress that involves checking if
> cleaner has acted.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/nio java/io`
> - [x] Linux AArch64 server fastdebug, `java/nio java/io`
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch6
On Wed, 12 Feb 2025 19:55:29 GMT, Stuart Marks wrote:
> A couple adjustments to the specs for four methods of StringBuilder and
> StringBuffer so that they no longer require new Strings to be created, just a
> String with the right contents. No implementation changes. Note that the
> actual sp
On Thu, 30 Jan 2025 16:25:30 GMT, Kim Barrett wrote:
>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be
>> used by WB? I assume this will at least add a comment to the method (or
>> whatever it changes to) to make it clear that it's for testing.
>
> @AlanBateman I'v
On Fri, 31 Jan 2025 17:17:04 GMT, Alan Bateman wrote:
> > One thing to think about: does this mean `protectionDomain` is now
> > discoverable by reflection? Should it be? Should it be filtered?
>
> Class::getProtectionDomain is a public API so anyone looking for it doesn't
> need reflection, b
On Fri, 31 Jan 2025 16:39:35 GMT, Coleen Phillimore wrote:
> This change removes the native call and injected field for ProtectionDomain
> in the java.lang.Class instance, and moves the field to be declared in Java.
> Tested with tier1-4.
One thing to think about: does this mean `protectionDoma
On Fri, 31 Jan 2025 15:01:08 GMT, Jorn Vernee wrote:
> This reverts https://github.com/openjdk/jdk/pull/23142
>
> See the JBS issue. It seems that the changes are occasionally causing heap
> corruption, potentially due to use after free, which occasionally results in
> corrupt malloc headers b
On Thu, 30 Jan 2025 16:54:16 GMT, Alan Bateman wrote:
>> @kimbarrett Do you have a change coming to allow waitForPendingReferences be
>> used by WB? I assume this will at least add a comment to the method (or
>> whatever it changes to) to make it clear that it's for testing.
>
>> @AlanBateman I
On Wed, 29 Jan 2025 19:42:49 GMT, Aleksey Shipilev wrote:
>> src/java.base/share/classes/java/lang/ref/Reference.java line 282:
>>
>>> 280: * This method returns a strong reference to the referent. This
>>> may cause
>>> 281: * the garbage coll
gt;
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/nio java/io`
> - [x] Linux AArch64 server fastdebug, `java/nio java/io`
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull req
On Wed, 29 Jan 2025 19:28:31 GMT, Kim Barrett wrote:
>> Aleksey Shipilev 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 cont
On Mon, 27 Jan 2025 09:08:56 GMT, Aleksey Shipilev wrote:
> > Would you mind holding off until Tuesday to give time to get that done?
>
> Sure, there is no rush with this PR. I'll wait.
How is it going, @AlanBateman? Any progress on closed tests?
-
On Sun, 26 Jan 2025 07:30:22 GMT, Alan Bateman wrote:
> Would you mind holding off until Tuesday to give time to get that done?
Sure, there is no rush with this PR. I'll wait.
-
PR Comment: https://git.openjdk.org/jdk/pull/22165#issuecomment-2615197062
On Fri, 24 Jan 2025 22:01:59 GMT, Brent Christian wrote:
> Did the change to
> `test/jdk/sun/security/provider/FileInputStreamPool/FileInputStreamPoolTest.java`
> get lost? I'm pretty sure it was updated, but I no longer see that in the
> changes, and it failed in my automated test run.
It wa
gt;
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/nio java/io`
> - [x] Linux AArch64 server fastdebug, `java/nio java/io`
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull reque
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
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 hasReferenc
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
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
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
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 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/BufferCle
gt;
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/nio java/io`
> - [x] Linux AArch64 server fastdebug, `java/nio java/io`
> - [ ] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the
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 hasReferenc
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
gt;
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `java/nio java/io`
> - [x] Linux AArch64 server fastdebug, `java/nio java/io`
> - [ ] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request
1 - 100 of 702 matches
Mail list logo
