eproducer ineffective.
>
> Additional testing:
> - [x] macos-aarch64-server-fastdebug,
> [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) reproducer now
> passes
> - [x] linux-aarch64-server-fastdebug, `all`
Aleksey Shipilev has updated the pull request with a new t
On Mon, 28 Oct 2024 22:36:44 GMT, Jiangli Zhou 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 Mon, 28 Oct 2024 22:28:34 GMT, Jiangli Zhou wrote:
>> This is forked from
>> [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642) and filed as a
>> general issue for archived boxed Integer cache when it's recreated at
>> runtime. In short, current code drops the entire primitive cache
On Mon, 28 Oct 2024 23:15:54 GMT, Vladimir Ivanov wrote:
> I have mixed feelings about proposed fix. It does look like an improvement
> over current behavior, but does it really address the root cause of the
> problem?
I think it does. It is important to separate two problems here: one of JLS
On Mon, 28 Oct 2024 23:15:36 GMT, Erik Joelsson wrote:
>> make/modules/jdk.accessibility/Launcher.gmk line 56:
>>
>>> 54: $(eval $(call SetupJdkExecutable, BUILD_JACCESSINSPECTOR, \
>>> 55: NAME := jaccessinspector, \
>>> 56: EXTRA_SRC := \
>>
>> I might be missing something here.
On Mon, 28 Oct 2024 18:15:38 GMT, Magnus Ihse Bursie wrote:
>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
>> Port_](https://openjdk.org/jeps/479).
>>
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port.
>>>
On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie wrote:
> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86
> Port_](https://openjdk.org/jeps/479).
>
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port.
>> This
This is forked from [JDK-8342642](https://bugs.openjdk.org/browse/JDK-8342642)
and filed as a general issue for archived boxed Integer cache when it's
recreated at runtime. In short, current code drops the entire primitive cache
when the CDS archived version of the cache is too short. This poses
On Fri, 25 Oct 2024 21:25:54 GMT, Jiangli Zhou wrote:
> Moved from
> https://github.com/openjdk/jdk/pull/21672/commits/ade90fb51d1e3652910a3b46775522b730306e16:
>
> Please review the fix that uses String type for the mapped value in
> ModuleLoaderMap.Mapper map (Map). Please see details in
>
On Thu, 24 Oct 2024 21:20:57 GMT, Jiangli Zhou wrote:
> In that sense, I think we don't have a risk of potentially with `used_Integer
> > IntegerCache.high`. The idea described in Ioi's comment above (also brought
> up by Aleksey Shipilev separately during premain meetin
When GH output is too large, we do not actually truncate it after
[JDK-8341424](https://bugs.openjdk.org/browse/JDK-8341424). The error log would
be:
Run bash ./.github/scripts/gen-test-results.sh "$GITHUB_STEP_SUMMARY"
./.github/scripts/gen-test-results.sh: line 28: report-utils.sh: No such fi
On Tue, 15 Oct 2024 11:07:32 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a pe
On Tue, 15 Oct 2024 10:02:15 GMT, Yudi Zheng wrote:
>> Aleksey Shipilev has updated the pull request with a new target base due to
>> a merge or a rebase. The pull request now contains 18 commits:
>>
>> - Simplify: just do keep alive checks
>> - Merge br
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit s
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
On Wed, 9 Oct 2024 08:44:34 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
On Mon, 7 Oct 2024 08:15:21 GMT, Erik Österlund wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> More precise bit-unmasks
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 34
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or
On Mon, 23 Sep 2024 18:45:49 GMT, Ioi Lam wrote:
> This is the 7th and final PR for [JEP 483: Ahead-of-Time Class Loading &
> Linking](https://bugs.openjdk.org/browse/JDK-8315737).
>
> This PR implements the AOT-linking of invokedynamic callsites:
> - We only link lambda expressions (`LambdaMet
On Sun, 6 Oct 2024 14:43:09 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [ ] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit si
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [ ] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or
On Wed, 2 Oct 2024 10:47:09 GMT, Tobias Hartmann wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also dispatch to slow-path on other arches
>
> test/micro/org/openjdk/bench/jav
On Thu, 3 Oct 2024 12:14:08 GMT, Erik Österlund wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Also dispatch to slow-path on other arches
>
> src/hotspot/share/opto/library_
On Tue, 1 Oct 2024 07:22:46 GMT, Matthias Baesken wrote:
> This fixes a format string issue.
>
> In the error report it was reported : 'The compiler should be able to catch
> this if JLI_ReportErrorMessageSys was declared with something like
> __attribute__ ((format (printf, 1, 2))).'
> Should
On Tue, 1 Oct 2024 13:15:51 GMT, Matthias Baesken wrote:
>> This fixes a format string issue.
>>
>> In the error report it was reported : 'The compiler should be able to catch
>> this if JLI_ReportErrorMessageSys was declared with something like
>> __attribute__ ((format (printf, 1, 2))).'
>>
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [ ] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit si
On Fri, 27 Sep 2024 23:51:13 GMT, Kim Barrett wrote:
>> Aleksey Shipilev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Amend the test case for guaranteing it works under different compilation
>> r
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [ ] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request incrementally with two additional
commits sin
On Mon, 30 Sep 2024 15:08:53 GMT, Erik Österlund wrote:
> I think we need a new
> ZBarrierSetRuntime::no_keepalive_store_barrier_on_oop_field_without_healing(oop*
> p) and to make that the selected slow path function when ZBarrierNoKeepalive
> is set on a StorePNode. Its implementation would c
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a r
On Fri, 27 Sep 2024 17:44:38 GMT, Vladimir Kozlov wrote:
> Is ZGC affected by this? I see only G1 and Shenandoah changes.
Good question.
ZGC expands the GC barriers late. This is why the IR test configuration that
tests ZGC shows the same result as with other collectors: no additional fluff
i
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
On Tue, 24 Sep 2024 20:21:48 GMT, Chen Liang wrote:
> This implementation code was written in JDK 7, before storeFence was
> available in JDK 8. We should update this legacy code to make it clear.
I have been harboring doubts `syncAll` even works (`FIXME: NYI` is fun) with a
lone barrier for a
On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann wrote:
> When investigating an intermittent NPE with an Oracle internal test on
> AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by
> `MethodHandles::jump_to_lambda_form` when trying to load the
> `MemberName::method`
On Tue, 24 Sep 2024 14:18:58 GMT, Tobias Hartmann wrote:
> When investigating an intermittent NPE with an Oracle internal test on
> AArch64, I noticed that the NPE is actually a SIGSEGV in the code emitted by
> `MethodHandles::jump_to_lambda_form` when trying to load the
> `MemberName::method`
On Tue, 24 Sep 2024 04:33:14 GMT, Jaikiran Pai wrote:
> Can I please get a review of this cleanup to the launcher code to remove
> declarations of unused functions?
>
> The `ValidateModules` function appears to be a left-over from
> https://bugs.openjdk.org/browse/JDK-8194937.
>
> The `SetApp
On Fri, 19 Jul 2024 15:52:14 GMT, Aleksey Shipilev wrote:
>> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
>> method for `Reference.clear`. The original patch skipped intrinsification of
>> this method, because we thought `Reference.clear` is no
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs wrote:
> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
>
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods,
> avoid removing
On Wed, 7 Aug 2024 19:26:59 GMT, Roger Riggs wrote:
> The original test fails intermittently, the reproducer failed consistently.
> With the fix, the failure was not observed in the test or reproducer.
>
> In jdk.internal.util.ReferencedKeyMap.entrySet() and toString() methods,
> avoid removing
On Wed, 31 Jul 2024 13:40:31 GMT, Jorn Vernee wrote:
> This test spawns 2 forked processes, which then try to trigger a code cache
> OOM in FFM hotspot code. Even without `-Xcomp`, the test is already pretty
> slow, which increases dramatically with `-Xcomp`, since startup Java code has
> to b
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [x] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request incrementally with one additional
commit
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a pe
On Fri, 12 Jul 2024 13:19:31 GMT, Aleksey Shipilev wrote:
>>> > The reason we did not do this before is that this is not a strong
>>> > reference store. Strong reference stores with a SATB collector will keep
>>> > the referent alive, which is typical
gt; intrinsics. C2 Access also need a support for `AS_NO_KEEPALIVE` for stores.
>
> Additional testing:
> - [x] Linux x86_64 server fastdebug, `all`
> - [ ] Linux AArch64 server fastdebug, `all`
Aleksey Shipilev has updated the pull request with a new target base due to a
merge or a
On Mon, 15 Jul 2024 13:39:02 GMT, Aleksey Shipilev wrote:
>> Indeed, for some reason I thought the range of short is -256 to 255 instead
>> of -65536 to 65535
>
>> Indeed, for some reason I thought the range of short is -256 to 255 instead
>> of -65536 to 65535
>
On Mon, 15 Jul 2024 15:57:30 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. Solution is to use bit flip on the actual index (and rename
>> the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and
>> 0 the de
On Mon, 15 Jul 2024 15:47:50 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/invoke/LambdaFormEditor.java line 778:
>>
>>> 776: var newParameters = new TreeMap(new
>>> Comparator<>() {
>>> 777: public int compare(Name n1, Name n2) {
>>> 778: r
On Mon, 15 Jul 2024 14:09:22 GMT, Chen Liang wrote:
>> The `@Stable` on the `index` field is incorrect, as stable only avoids
>> inlining `0`. Solution is to use bit flip on the actual index (and rename
>> the field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and
>> 0 the de
On Thu, 20 Jun 2024 19:17:25 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to s
On Mon, 15 Jul 2024 12:28:51 GMT, Chen Liang wrote:
> Indeed, for some reason I thought the range of short is -256 to 255 instead
> of -65536 to 65535
Yeah, I thought something like this was going on; it would be a smart way to
leverage that negative side in two-complement form is one value la
On Mon, 15 Jul 2024 01:45:57 GMT, Chen Liang wrote:
> The `@Stable` on the `index` field is incorrect, as stable only avoids
> inlining `0`. Solution is to use bit flip on the actual index (and rename the
> field to `flippedIndex`), so we use -1 to -256 (mapping to 0 to 255) and 0
> the defaul
On Fri, 12 Jul 2024 11:57:56 GMT, Erik Österlund wrote:
> The runtime use of the Access API knows how to resolve an unknown oop ref
> strength using AccessBarrierSupport::resolve_unknown_oop_ref_strength.
> However, we do not have support for that in the C2 backend. In fact, it does
> not unde
On Fri, 12 Jul 2024 10:16:13 GMT, Erik Österlund wrote:
> The reason we did not do this before is that this is not a strong reference
> store. Strong reference stores with a SATB collector will keep the referent
> alive, which is typically the exact opposite of what a user wants when they
> cl
On Thu, 11 Jul 2024 15:28:37 GMT, Aleksey Shipilev wrote:
> [JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
> method for `Reference.clear`. The original patch skipped intrinsification of
> this method, because we thought `Reference.clear` is not on a pe
[JDK-8240696](https://bugs.openjdk.org/browse/JDK-8240696) added the native
method for `Reference.clear`. The original patch skipped intrinsification of
this method, because we thought `Reference.clear` is not on a performance
sensitive path. However, it shows up prominently on simple benchmarks
On Tue, 11 Jun 2024 08:58:34 GMT, Aleksey Shipilev wrote:
>> Sean Gwizdak 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 Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev wrote:
> I was auditing the current uses of `@Stable` before relaxing its barriers
> ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an
> easy spot.
>
> `resolvedEnum` is not `final`. So technically
On Thu, 27 Jun 2024 19:30:34 GMT, Aleksey Shipilev wrote:
> I was auditing the current uses of `@Stable` before relaxing its barriers
> ([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an
> easy spot.
>
> `resolvedEnum` is not `final`. So technically
I was auditing the current uses of `@Stable` before relaxing its barriers
([JDK-8333791](https://bugs.openjdk.org/browse/JDK-8333791)), and this is an
easy spot.
`resolvedEnum` is not `final`. So technically publishing the object via data
race can show `resolvedEnum` as `null`, which would bre
On Thu, 6 Jun 2024 12:46:36 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to si
On Mon, 3 Jun 2024 18:00:35 GMT, Sean Gwizdak wrote:
>> Improve the speed of Method.hashCode by caching the hashcode on first use.
>> I've seen an application where Method.hashCode is a hot path, and this is a
>> fairly simple speedup. The memory overhead is low.
>>
>> This addresses issue
>
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/pull/19332) with t
On Thu, 6 Jun 2024 12:46:36 GMT, jengebr wrote:
>> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
>> cloning of Object[0] instances. This cloning is intended to prevent callers
>> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
>> to si
On Wed, 5 Jun 2024 14:56:26 GMT, jengebr wrote:
> clone() performs a shallow copy, so there is currently no Object[] allocated
> and therefore nothing to optimize.
Yes, I believe so.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/19527#discussion_r1629666551
On Wed, 5 Jun 2024 19:21:56 GMT, Jorn Vernee wrote:
> These 4 tests were failing due to an incompatibility with jcstress. They were
> problemlisted in past (https://bugs.openjdk.org/browse/JDK-8326062).
>
> Now that jcstress has been updated
> (https://github.com/openjdk/jdk/pull/19332) with t
On Mon, 3 Jun 2024 16:47:20 GMT, jengebr wrote:
> Improve `java/util/concurrent/CopyOnWriteArrayList` by eliminating needless
> cloning of Object[0] instances. This cloning is intended to prevent callers
> from changing array contents, but many `CopyOnWriteArrayList`s are allocated
> to size z
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 18:39:33 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 17:59:18 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but many Methods have zero exceptions or zero
>> parameters, and
On Fri, 31 May 2024 16:21:36 GMT, jengebr wrote:
>> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
>> Class[0] instances. This cloning is intended to prevent callers from
>> changing array contents, but smany Methods have zero exceptions or zero
>> parameters, and
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and ret
On Wed, 22 May 2024 14:32:23 GMT, Chen Liang wrote:
>> Thanks. Unfortunately the variable `cloneArray` is actually a method
>> parameter, and most of the callers pass in `false` - so using this utility
>> method to control cloning would actually introduce cloning in several places
>> where it
On Wed, 22 May 2024 19:48:49 GMT, Chen Liang wrote:
>> I really see no reason to try and save on re-use of this one-line method for
>> _everything_. In fact, I do not quite see a very compelling reason to even
>> have the utility method. Sharing the code between `Method` and `Constructor`
>> i
On Tue, 21 May 2024 13:49:18 GMT, jengebr wrote:
> Improve `java/lang/reflect/Method.java` by eliminating needless cloning of
> Class[0] instances. This cloning is intended to prevent callers from
> changing array contents, but smany Methods have zero exceptions or zero
> parameters, and ret
On Fri, 26 Apr 2024 08:45:45 GMT, Claes Redestad wrote:
>> Splitting out the ASM-based version from #18690 to push that first under the
>> JBS (to help backporting). Keeping #18690 open to rebase and follow-up on
>> this as a subtask. See discussion in that #18690 for more details,
>> discussi
On Wed, 24 Apr 2024 10:01:47 GMT, Claes Redestad wrote:
> > I really wish this change was not done with ClassFile API, but with a
> > simple bundled ASM, so it would be easily backportable, if we decide to. It
> > does not look like CFA buys us a lot here readability/complexity wise:
> > [d99b
On Thu, 18 Apr 2024 14:50:30 GMT, Claes Redestad wrote:
>> This patch suggests a workaround to an issue with huge SCF MH expression
>> trees taking excessive JIT compilation resources by reviving (part of) the
>> simple bytecode-generating strategy that was originally available as an
>> all-or
On Tue, 12 Mar 2024 18:42:48 GMT, Erik Joelsson wrote:
>> Chad Rakoczy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Code cleanup
>
> I'm fine with just using VERSION_FEATURE. I think it's a simple and
> straightforward enough simplif
On Wed, 13 Mar 2024 17:11:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Tue, 12 Mar 2024 19:22:25 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Tue, 12 Mar 2024 23:44:45 GMT, Magnus Ihse Bursie wrote:
>> Chad Rakoczy has updated the pull request incrementally with two additional
>> commits since the last revision:
>>
>> - Print to stdout instead of stderr
>> - Compare version using VERSION_STRING
>
> make/modules/java.base/Launche
On Tue, 12 Mar 2024 21:52:31 GMT, Elif Aslan wrote:
> This change enables to run JspawnhelperProtocol.java on MacOS.
>
> In addition to GHA , the test has been run on macos and linux.
>
>
> Test report is stored in
> build/macosx-x86_64-server-fastdebug/test-results/jtreg_test_jdk_java_lang_P
On Mon, 11 Mar 2024 19:12:33 GMT, Chad Rakoczy wrote:
>> Fix for [8325621](https://bugs.openjdk.org/browse/JDK-8325621)
>>
>> Updates jspawnhelper to check that JDK version and jspawnhelper version are
>> the same. Updates test to include check for version. Also tested manually by
>> replacing
On Mon, 11 Mar 2024 18:56:21 GMT, Bernd wrote:
> with a protocol version you don’t have to care about micro versions and also
> it is more tolerant about the usual cpu updates which do not introduce
> incompatibilities most of the time.
I think we can only reasonably guarantee that jspawnhelpe
On Mon, 11 Mar 2024 18:16:53 GMT, Erik Joelsson wrote:
> If you really want to require an exact match for jspawnhelper, then these 4
> numbers aren't necessarily enough, but a rather arbitrarily chosen
> approximation.
I think for our purposes, a version number quadruplet is enough to provide
On Fri, 8 Mar 2024 10:17:08 GMT, Magnus Ihse Bursie wrote:
> We should match the building of jspawnhelper in
> make/modules/java.base/Launcher.gmk with the usage for all unix platforms in
> src/java.base/unix/classes/java/lang/ProcessImpl.java.
>
> Granted, the list of OSes in the makefile amo
On Fri, 8 Mar 2024 07:35:27 GMT, Magnus Ihse Bursie wrote:
>> test/jdk/java/lang/ProcessBuilder/JspawnhelperWarnings.java line 29:
>>
>>> 27: * @test
>>> 28: * @bug 8325567
>>> 29: * @requires (os.family == "linux") | (os.family == "aix")
>>
>> Unless I'm mistaken, jspawn helper is used on M
On Thu, 7 Mar 2024 20:04:13 GMT, Vladimir Petko wrote:
> I wonder if it would make sense to add a test with a correct argument format?
I would say that is what current jspawnhelper tests already test, and it is
also tested implicitly with `Process` tests. Let's keep this test for testing
that
On Tue, 5 Mar 2024 17:56:21 GMT, Roger Riggs wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make CO
On Thu, 7 Mar 2024 17:13:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make CON
On Thu, 7 Mar 2024 16:29:12 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make CON
On Thu, 7 Mar 2024 16:33:11 GMT, Elif Aslan wrote:
>> This change is intended to address the segmentation fault issue that occurs
>> when jspawnhelper is called without arguments,.
>> There is a new test added to verify the behavior in such cases.
>>
>> `[ec2-user@ip-172-16-0-10 jdk]$ make CON
On Tue, 5 Mar 2024 20:34:47 GMT, Vladimir Petko wrote:
> > The change in jspawnhelper looks good.
> > I think it would be simpler to have a separate
> > `jdk/java/lang/ProcessBuilder/JspawnhelperMisuse.java` test that simply
> > invokes the `jspawnhelper` and verifies the proper message is prin
On Mon, 4 Mar 2024 21:19:26 GMT, Elif Aslan wrote:
> This change is intended to address the segmentation fault issue that occurs
> when jspawnhelper is called without arguments, and it includes an updated
> test to verify the behavior in such cases.
>
> Existing tests passes since it does not
On Thu, 22 Feb 2024 07:23:04 GMT, SendaoYan wrote:
> Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all
> the files in build/linux-x86_64-server-release/images/jdk/bin are executable:
>
> , redundant (covered by other tests
> like StringSubstring or the various String concatenation tests), or both.
> This cle
On Tue, 20 Feb 2024 18:38:48 GMT, Claes Redestad wrote:
>> JDK-8282429 accidentally removed an optimization (JDK-8240094) that ensured
>> StringBuilder/StringBuffer::toString returns `""` when the builders are
>> empty.
>>
>>
>> Name Cnt Base Error Test Er
101 - 200 of 595 matches
Mail list logo
