RFR: 8326461: tools/jlink/CheckExecutable.java fail after JDK-8325342
Before JDK-8325342(commit id:0bcece995840777db660811e4b20bb018e90439b), all the files in build/linux-x86_64-server-release/images/jdk/bin are executable:  After JDK-8325342, all the *.debuginfo files in build/linux-x86_64-server-release/images/jdk/bin are not executable:  This PR only modifies the testcase to adapt to the modification of the corresponding build script, ignoring the check of debuginfo file executable permissions, and the risk is low - Commit messages: - 8326461: tools/jlink/CheckExecutable.java fail after JDK-8325342 Changes: https://git.openjdk.org/jdk/pull/17958/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17958&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326461 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17958.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17958/head:pull/17958 PR: https://git.openjdk.org/jdk/pull/17958
Re: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v3]
On Thu, 22 Feb 2024 05:38:19 GMT, Chen Liang wrote: >> API changes as discussed on the mailing list: >> https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html >> >> Additional questions: >> 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` > > Chen Liang has updated the pull request with a new target base due to a merge > or a rebase. The pull request now contains 11 commits: > > - Rename no wildcard indicator, improve docs slightly > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/typearg-model > - Merge branch 'master' into fix/typearg-model > - redundant line > - Fix a test in langtools, copyright year > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/typearg-model > - Implementation cleanup, test update > - Merge branch 'master' into fix/typearg-model > - Formatting > - Nuke signatureString and fix test fialure from bad cast > - ... and 1 more: https://git.openjdk.org/jdk/compare/0bcece99...62d25642 @asotona How does this patch look for the roadmap of Class-File API 2nd review? Brian agreed to it before, will we consider or reject this? - PR Comment: https://git.openjdk.org/jdk/pull/16517#issuecomment-1958743153
Re: RFR: 8326227: Rounding error that may distort computeNextGaussian results [v3]
On Thu, 22 Feb 2024 03:01:58 GMT, Chris Hennick wrote: > Update: confirmed that the new test fails without the fix. Thanks for verifying the test checks the fix; I'll let others who have worked more directly on the random code review the actual fix. - PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1958740871
Re: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v3]
> API changes as discussed on the mailing list: > https://mail.openjdk.org/pipermail/classfile-api-dev/2023-November/000419.html > > Additional questions: > 1. Whether to rename `WildcardIndicator.DEFAULT` to `NONE` Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Rename no wildcard indicator, improve docs slightly - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model - Merge branch 'master' into fix/typearg-model - redundant line - Fix a test in langtools, copyright year - Merge branch 'master' of https://github.com/openjdk/jdk into fix/typearg-model - Implementation cleanup, test update - Merge branch 'master' into fix/typearg-model - Formatting - Nuke signatureString and fix test fialure from bad cast - ... and 1 more: https://git.openjdk.org/jdk/compare/0bcece99...62d25642 - Changes: https://git.openjdk.org/jdk/pull/16517/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16517&range=02 Stats: 132 lines in 6 files changed: 49 ins; 32 del; 51 mod Patch: https://git.openjdk.org/jdk/pull/16517.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16517/head:pull/16517 PR: https://git.openjdk.org/jdk/pull/16517
Re: RFR: 8323707: Adjust Classfile API's type arg model to better represent the embodied type [v3]
On Mon, 19 Feb 2024 15:28:23 GMT, David M. Lloyd wrote: >> src/java.base/share/classes/java/lang/classfile/Signature.java line 219: >> >>> 217: * no wildcard (empty), an exact type >>> 218: */ >>> 219: DEFAULT, >> >> I’m personally in favour of naming this `NONE`. > > A belated +1 to this, at least not calling it `DEFAULT` because that has at > best no meaning, and at worst it's outright confusing. If not `NONE`, then > what about `EXACT`? > > In my own old parsing code I have an enum called `Variance` with values > `INVARIANT`, `COVARIANT`, and `CONTRAVARIANT`, but that might be a bit > confusing considering that `EXTENDS` and `SUPER` match the Java language > keywords directly. > > As an aside, the javadoc here could be a little better IMO. Performed the rename. `NONE` is better than `EXACT`, as there indeed is no indicator char for this bounded type argument. I have added the terms of `invariant` `covariant` `contravariant` to the docs, so that they can be searched with the Javadoc search function. (These are official CS terms so shouldn't be ambiguous) I decided not too add exact descriptions, like "method parameters EXTENDS can only accept null" or "method return type SUPER can only return Object". These details of Java type system may be subject to change in the future, and this is really describing details of a ClassFile attribute instead of the Java type system. - PR Review Comment: https://git.openjdk.org/jdk/pull/16517#discussion_r1498670793
Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v13]
> Re-write the IndexOf code without the use of the pcmpestri instruction, only > using AVX2 instructions. This change accelerates String.IndexOf on average > 1.3x for AVX2. The benchmark numbers: > > > BenchmarkScore > Latest > StringIndexOf.advancedWithMediumSub 343.573 317.934 > 0.925375393x > StringIndexOf.advancedWithShortSub1 1039.081 1053.96 > 1.014319384x > StringIndexOf.advancedWithShortSub2 55.828110.541 > 1.980027943x > StringIndexOf.constantPattern 9.361 11.906 > 1.271872663x > StringIndexOf.searchCharLongSuccess 4.216 4.218 > 1.000474383x > StringIndexOf.searchCharMediumSuccess 3.133 3.216 > 1.02649218x > StringIndexOf.searchCharShortSuccess 3.763.761 > 1.000265957x > StringIndexOf.success 9.186 9.713 > 1.057369911x > StringIndexOf.successBig14.34146.343 > 3.231504079x > StringIndexOfChar.latin1_AVX2_String6220.918 12154.52 > 1.953814533x > StringIndexOfChar.latin1_AVX2_char 5503.556 5540.044 > 1.006629895x > StringIndexOfChar.latin1_SSE4_String6978.854 6818.689 > 0.977049957x > StringIndexOfChar.latin1_SSE4_char 5657.499 5474.624 > 0.967675646x > StringIndexOfChar.latin1_Short_String 7132.541 6863.359 > 0.962260014x > StringIndexOfChar.latin1_Short_char 16013.389 16162.437 > 1.009307711x > StringIndexOfChar.latin1_mixed_String 7386.12314771.622 > 1.15517x > StringIndexOfChar.latin1_mixed_char 9901.671 9782.245 > 0.987938803 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Addressed some review coments; replaced hard-coded registers with descriptive names. - Changes: - all: https://git.openjdk.org/jdk/pull/16753/files - new: https://git.openjdk.org/jdk/pull/16753/files/62e4e8b1..82bcd8b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=11-12 Stats: 484 lines in 3 files changed: 174 ins; 80 del; 230 mod Patch: https://git.openjdk.org/jdk/pull/16753.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753 PR: https://git.openjdk.org/jdk/pull/16753
Re: RFR: 8326227: Rounding error that may distort computeNextGaussian results [v3]
On Wed, 21 Feb 2024 02:18:08 GMT, Chris Hennick wrote: >> This provides a slightly more accurate bounding limit for >> `computeNextExponentialSoftCapped` when the computed bound is greater than >> `(1.0p53 - 1.0) * DoubleZigguratTables.exponentialX0`. This could cause the >> `while (computeNextExponentialSoftCapped(rng, limit) < limit)` check in >> `computeNextGaussian` on line 1402 to always be true, making the >> `nextGaussian` runtime unbounded in the worst case. >> >> This change is being tested prior to submission to OpenJDK by >> https://github.com/openjdk/jdk/pull/17703/commits/b8be051cbf40a6a05fafc6a2c76942e9e0b11fdf. > > Chris Hennick has updated the pull request incrementally with one additional > commit since the last revision: > > Bug fix: add-exports was for wrong package Update: confirmed that the new test fails without the fix. - PR Comment: https://git.openjdk.org/jdk/pull/17703#issuecomment-1958571446
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
On Thu, 22 Feb 2024 01:42:17 GMT, Brent Christian wrote: >> Classes in the `java.lang.ref` package would benefit from an update to bring >> the spec in line with how the VM already behaves. The changes would focus on >> _happens-before_ edges at some key points during reference processing. >> >> A couple key things we want to be able to say are: >> - `Reference.reachabilityFence(x)` _happens-before_ reference processing >> occurs for 'x'. >> - `Cleaner.register()` _happens-before_ the Cleaner thread runs the >> registered cleaning action. >> >> This will bring Cleaner in line (or close) with the memory visibility >> guarantees made for finalizers in [JLS >> 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): >> _"There is a happens-before edge from the end of a constructor of an object >> to the start of a finalizer (§12.6) for that object."_ > > Brent Christian has updated the pull request incrementally with one > additional commit since the last revision: > > Cleaner thread dequeue happens-before running cleaning action Looks good. It is a thumbs up from me. - Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/16644#pullrequestreview-1894716637
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v9]
> Classes in the `java.lang.ref` package would benefit from an update to bring > the spec in line with how the VM already behaves. The changes would focus on > _happens-before_ edges at some key points during reference processing. > > A couple key things we want to be able to say are: > - `Reference.reachabilityFence(x)` _happens-before_ reference processing > occurs for 'x'. > - `Cleaner.register()` _happens-before_ the Cleaner thread runs the > registered cleaning action. > > This will bring Cleaner in line (or close) with the memory visibility > guarantees made for finalizers in [JLS > 17.4.5](https://docs.oracle.com/javase/specs/jls/se18/html/jls-17.html#jls-17.4.5): > _"There is a happens-before edge from the end of a constructor of an object > to the start of a finalizer (§12.6) for that object."_ Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Cleaner thread dequeue happens-before running cleaning action - Changes: - all: https://git.openjdk.org/jdk/pull/16644/files - new: https://git.openjdk.org/jdk/pull/16644/files/1ca169ec..0f949d3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16644&range=07-08 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16644.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16644/head:pull/16644 PR: https://git.openjdk.org/jdk/pull/16644
Re: RFR: 8314480: Memory ordering spec updates in java.lang.ref [v8]
On Wed, 21 Feb 2024 01:52:57 GMT, David Holmes wrote: >> Brent Christian has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Updates to reachabilityFence() > > src/java.base/share/classes/java/lang/ref/package-info.java line 118: > >> 116: * >> 117: * The Cleaner thread dequeues a reference to a registered object >> before >> 118: * running the cleaning action for that object. > > Do you want to rephrase this so that it too mentions `happens-before`? e.g. > > Dequeuing of a reference to a registered object, by the Cleaner thread, > happens-before the execution of the cleaning action for that object. I hesitated to state it that way because there's not a synchronization action _per se_ between the Cleaning thread dequeuing, and then running the cleaning action. However, I see that JLS 17.4.5 does state: _"If x and y are actions of the same thread and x comes before y in program order, then hb(x, y)."_ (That is, x _happens-before_ y). So yes, we can say _happens-before_ here. Thanks! - PR Review Comment: https://git.openjdk.org/jdk/pull/16644#discussion_r1498493650
Re: RFR: 8310994: Add JFR event for selection operations [v5]
> Added mirror event with static methods: jdk.internal.event.SelectionEvent > that provides the duration of select calls and the count of how many keys are > available. > > Emit the event from SelectorImpl::lockAndDoSelect > > Test at jdk.jfr.event.io.TestSelectionEvents Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - update copyright dates - Merge branch 'master' into JDK-8310994 # Conflicts: #src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java #src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java - comment fixup - add select timeout field to the event - Change event generation: - selectNow is filtered out - select that times out is always sent - select without timeout uses duration test - rename event to SelectorSelect, field to selectionKeyCount. - Merge branch 'master' into JDK-8310994 - remove trailing whitespace - event logic outside of the lock, selector in try block - remove unused import - ... and 6 more: https://git.openjdk.org/jdk/compare/36246c97...2e11e84a - Changes: https://git.openjdk.org/jdk/pull/16710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=04 Stats: 321 lines in 9 files changed: 317 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/16710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710 PR: https://git.openjdk.org/jdk/pull/16710
Re: RFR: 8309622: Re-examine the cache mechanism in BaseLocale [v7]
> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where > aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the > in-house cache with WeakHashMap, and removed the Key class as it is no longer > needed (thus the original NPE will no longer be possible). Also with the new > JMH test case, it gains some performance improvement: > > (w/o fix) > > Benchmark Mode Cnt Score Error Units > LocaleCache.testForLanguageTag avgt 20 5781.275 ± 569.580 ns/op > LocaleCache.testLocaleOfavgt 20 62564.079 ± 406.697 ns/op > > (w/ fix) > Benchmark Mode Cnt Score Error Units > LocaleCache.testForLanguageTag avgt 20 4801.175 ± 371.830 ns/op > LocaleCache.testLocaleOfavgt 20 60394.652 ± 352.471 ns/op Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Use ReferencedKeySet.intern() - Merge branch 'master' into JDK-8309622-Cache-BaseLocale - Merge branch 'master' into JDK-8309622-Cache-BaseLocale - Restored the test - Merge branch 'master' into JDK-8309622-Cache-BaseLocale - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale - small cleanup - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale - Update ReferencedKeyTest.java - Simple versions of create - ... and 24 more: https://git.openjdk.org/jdk/compare/b419e951...32ec51f7 - Changes: https://git.openjdk.org/jdk/pull/14404/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14404&range=06 Stats: 524 lines in 6 files changed: 129 ins; 267 del; 128 mod Patch: https://git.openjdk.org/jdk/pull/14404.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14404/head:pull/14404 PR: https://git.openjdk.org/jdk/pull/14404
Re: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library [v2]
> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with
> AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from
> HotSpotVirtualMachine.processCompletionStatus (called from
> HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach
> return code ("return code: %d" message).
>
> before jdk21 if attach listener fails to load required library, it returned
> error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary
> read only single line of the response message, so exception message didn't
> contain error details.
>
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole
> response message.
> Walking through the code, fixed some other minor things in attach listener
> and attach API implementation (commented in the code)
>
> Testing:
> - test/jdk/com/sun/tools;
> - tier1,tier2,tier5-svc
Alex Menkov has updated the pull request incrementally with one additional
commit since the last revision:
uncaught error
-
Changes:
- all: https://git.openjdk.org/jdk/pull/17954/files
- new: https://git.openjdk.org/jdk/pull/17954/files/19f0822e..0304bae2
Webrevs:
- full: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=01
- incr: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00-01
Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
Patch: https://git.openjdk.org/jdk/pull/17954.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954
PR: https://git.openjdk.org/jdk/pull/17954
Re: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library
On Wed, 21 Feb 2024 21:16:46 GMT, Alex Menkov wrote:
>> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with
>> AgentLoadException in 2 cases:
>> - attach listener returns error; in the case the exception is thrown from
>> HotSpotVirtualMachine.processCompletionStatus (called from
>> HotSpotVirtualMachine.execute);
>> - attach listener returns success, but reply does not contain Agent_onAttach
>> return code ("return code: %d" message).
>>
>> before jdk21 if attach listener fails to load required library, it returned
>> error (case 1)
>> from jdk21 attach listener always returns success (case 2)
>> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary
>> read only single line of the response message, so exception message didn't
>> contain error details.
>>
>> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole
>> response message.
>> Walking through the code, fixed some other minor things in attach listener
>> and attach API implementation (commented in the code)
>>
>> Testing:
>> - test/jdk/com/sun/tools;
>> - tier1,tier2,tier5-svc
>
> src/hotspot/share/prims/jvmtiAgentList.cpp line 201:
>
>> 199:
>> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime.
>> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char*
>> absParam,
>
> The method never returns error, dropped value return type
only 1 caller (load_agent() from attachListener) extract `absParam` from attach
command, other pass constants ("true" or "false")
Moved conversion from string to bool there.
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498327164
Re: RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library
On Wed, 21 Feb 2024 21:13:36 GMT, Alex Menkov wrote:
> VirtualMachine.loadAgentPath/loadAgentLibrary can fail with
> AgentLoadException in 2 cases:
> - attach listener returns error; in the case the exception is thrown from
> HotSpotVirtualMachine.processCompletionStatus (called from
> HotSpotVirtualMachine.execute);
> - attach listener returns success, but reply does not contain Agent_onAttach
> return code ("return code: %d" message).
>
> before jdk21 if attach listener fails to load required library, it returned
> error (case 1)
> from jdk21 attach listener always returns success (case 2)
> Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary
> read only single line of the response message, so exception message didn't
> contain error details.
>
> The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole
> response message.
> Walking through the code, fixed some other minor things in attach listener
> and attach API implementation (commented in the code)
>
> Testing:
> - test/jdk/com/sun/tools;
> - tier1,tier2,tier5-svc
src/hotspot/share/prims/jvmtiAgentList.cpp line 127:
> 125: }
> 126:
> 127: void JvmtiAgentList::add(const char* name, const char* options, bool
> absolute_path) {
`options` parameter should be const
src/hotspot/share/prims/jvmtiAgentList.cpp line 131:
> 129: }
> 130:
> 131: void JvmtiAgentList::add_xrun(const char* name, const char* options,
> bool absolute_path) {
`options` parameter should be const
src/hotspot/share/prims/jvmtiAgentList.cpp line 201:
> 199:
> 200: // Invokes Agent_OnAttach for agents loaded dynamically during runtime.
> 201: jint JvmtiAgentList::load_agent(const char* agent_name, const char*
> absParam,
The method never returns error, dropped value return type
src/jdk.attach/share/classes/sun/tools/attach/HotSpotVirtualMachine.java line
402:
> 400: }
> 401:
> 402: // Special-case the "load" command so that the right
> exception is
We had special logic for "load" command in 2 places (here and in the
loadAgentLibrary method)
For simplification moved all logic to loadAgentLibrary()
-
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320621
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498320775
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498321476
PR Review Comment: https://git.openjdk.org/jdk/pull/17954#discussion_r1498333650
RFR: JDK-8325530: Vague error message when com.sun.tools.attach.VirtualMachine fails to load agent library
VirtualMachine.loadAgentPath/loadAgentLibrary can fail with AgentLoadException
in 2 cases:
- attach listener returns error; in the case the exception is thrown from
HotSpotVirtualMachine.processCompletionStatus (called from
HotSpotVirtualMachine.execute);
- attach listener returns success, but reply does not contain Agent_onAttach
return code ("return code: %d" message).
before jdk21 if attach listener fails to load required library, it returned
error (case 1)
from jdk21 attach listener always returns success (case 2)
Both cases are ok, but for 2nd case HotSpotVirtualMachine.loadAgentLibrary read
only single line of the response message, so exception message didn't contain
error details.
The fix updates HotSpotVirtualMachine.loadAgentLibrary to read the whole
response message.
Walking through the code, fixed some other minor things in attach listener and
attach API implementation (commented in the code)
Testing:
- test/jdk/com/sun/tools;
- tier1,tier2,tier5-svc
-
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/17954/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17954&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8325530
Stats: 146 lines in 6 files changed: 106 ins; 16 del; 24 mod
Patch: https://git.openjdk.org/jdk/pull/17954.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/17954/head:pull/17954
PR: https://git.openjdk.org/jdk/pull/17954
Re: RFR: 8325579: Inconsistent behavior in com.sun.jndi.ldap.Connection::createSocket [v5]
On Tue, 20 Feb 2024 10:28:37 GMT, Christoph Langer wrote: > Hm, I think the test was overpurposed already. This test was added by JDK-8314063 fix, and I do not think it was change after that. > Creating another test file with duplicating code does not sound too good > IMHO. Maybe it is acceptable without the renaming? I think it is acceptable. Currently, it is hard to separate the test cases for `a)` the original [JDK-8314063](https://bugs.openjdk.org/browse/JDK-8314063) fix (the opened socket is not closed properly when connection timeout occurs) and `b)` the current fix [JDK-8325579](https://bugs.openjdk.org/browse/JDK-8325579) (unconnected sockets are not supported by SocketFactory). It would be great to have this distinction in the modified test. - PR Comment: https://git.openjdk.org/jdk/pull/17797#issuecomment-1957632827
Integrated: 8326158: Javadoc for java.time.DayOfWeek#minus(long)
On Tue, 20 Feb 2024 18:34:59 GMT, Naoto Sato wrote: > Fixing a typo in the said method. This pull request has now been integrated. Changeset: 64f7972a Author:Naoto Sato URL: https://git.openjdk.org/jdk/commit/64f7972a3d0c82ad7047f73f0b57c3d88f62935f Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8326158: Javadoc for java.time.DayOfWeek#minus(long) Reviewed-by: iris, lancea - PR: https://git.openjdk.org/jdk/pull/17933
Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v12]
> Re-write the IndexOf code without the use of the pcmpestri instruction, only > using AVX2 instructions. This change accelerates String.IndexOf on average > 1.3x for AVX2. The benchmark numbers: > > > BenchmarkScore > Latest > StringIndexOf.advancedWithMediumSub 343.573 317.934 > 0.925375393x > StringIndexOf.advancedWithShortSub1 1039.081 1053.96 > 1.014319384x > StringIndexOf.advancedWithShortSub2 55.828110.541 > 1.980027943x > StringIndexOf.constantPattern 9.361 11.906 > 1.271872663x > StringIndexOf.searchCharLongSuccess 4.216 4.218 > 1.000474383x > StringIndexOf.searchCharMediumSuccess 3.133 3.216 > 1.02649218x > StringIndexOf.searchCharShortSuccess 3.763.761 > 1.000265957x > StringIndexOf.success 9.186 9.713 > 1.057369911x > StringIndexOf.successBig14.34146.343 > 3.231504079x > StringIndexOfChar.latin1_AVX2_String6220.918 12154.52 > 1.953814533x > StringIndexOfChar.latin1_AVX2_char 5503.556 5540.044 > 1.006629895x > StringIndexOfChar.latin1_SSE4_String6978.854 6818.689 > 0.977049957x > StringIndexOfChar.latin1_SSE4_char 5657.499 5474.624 > 0.967675646x > StringIndexOfChar.latin1_Short_String 7132.541 6863.359 > 0.962260014x > StringIndexOfChar.latin1_Short_char 16013.389 16162.437 > 1.009307711x > StringIndexOfChar.latin1_mixed_String 7386.12314771.622 > 1.15517x > StringIndexOfChar.latin1_mixed_char 9901.671 9782.245 > 0.987938803 Scott Gibbons has updated the pull request incrementally with one additional commit since the last revision: Fix slowdebug compile issues. - Changes: - all: https://git.openjdk.org/jdk/pull/16753/files - new: https://git.openjdk.org/jdk/pull/16753/files/71ebf9e7..62e4e8b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16753&range=10-11 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16753.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16753/head:pull/16753 PR: https://git.openjdk.org/jdk/pull/16753
Re: RFR: JDK-8320448 Accelerate IndexOf using AVX2 [v8]
On Tue, 20 Feb 2024 09:49:23 GMT, Jatin Bhateja wrote: >> Thank you all for the reviews. I have been asked to simplify this code to >> facilitate easier review, and to remove the gcc library code I used for >> memcmp. We also discovered that special-casing up to 31 bytes of needle was >> not necessary to get the performance gain. I will be commenting the code >> and fixing the single build failure soon. > > Hi @asgibbons , > > I am getting following error with slowdebug build on Meteor Lake system. > > > ERROR: Build failed for target 'images' in configuration > 'linux-x86_64-server-slowdebug' (exit code 2) > > === Output from failing command(s) repeated here === > * For target > buildtools_create_symbols_javac__the.COMPILE_CREATE_SYMBOLS_batch: > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/home/jatinbha/sandboxes/jdk-reviews/jdk/src/hotspot/share/asm/assembler.hpp:169), > pid=237140, tid=237235 > # assert(is_bound() || is_unused()) failed: Label was never bound to a > location, but it was used as a jmp target > # > # JRE version: OpenJDK Runtime Environment (23.0) (slowdebug build > 23-internal-adhoc.sdp.jdk) > # Java VM: OpenJDK 64-Bit Server VM (slowdebug 23-internal-adhoc.sdp.jdk, > mixed mode, tiered, compressed oops, compressed class ptrs, g1 gc, > linux-amd64) > # Problematic frame: > # V [libjvm.so+0x4c9e3e] Label::~Label()+0x5c > # > # Core dump will be written. Default location: Core dumps may be processed > with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or > dumping to /home/jatinbha/sandboxes/jdk-reviews/jdk/make/core.237140) > # > # An error report file with more information is saved as: > # /home/jatinbha/sandboxes/jdk-reviews/jdk/make/hs_err_pid237140.log >... (rest of output omitted) @jatin-bhateja Thanks for the note. Fixed a couple of slowdebug compile issues. Now builds successfully on Meteor Lake system. - PR Comment: https://git.openjdk.org/jdk/pull/16753#issuecomment-1957038856
RFR: JDK-8326389: [test] improve assertEquals failure output
Currently assertEquals has in the failure case sometimes confusing output like : java.lang.RuntimeException: VM output should contain exactly one RTM locking statistics entry for method compiler.rtm.locking.TestRTMTotalCountIncrRate$Test:🔒 expected 0 to equal 1 at jdk.test.lib.Asserts.fail(Asserts.java:634) at jdk.test.lib.Asserts.assertEquals(Asserts.java:205) (I don't think we really expected that for some reason 0 equals 1) This should be improved. - Commit messages: - JDK-8326389 Changes: https://git.openjdk.org/jdk/pull/17952/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17952&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326389 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17952.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17952/head:pull/17952 PR: https://git.openjdk.org/jdk/pull/17952
RFR: 8325754: Dead AbstractQueuedSynchronizer$ConditionNodes survive minor garbage collections
More aggressively breaking chains in order to prevent nodes promoted to older generations standing in the way for collecting younger nodes. I decided that it was most efficient to add this logic to the else-branch of updating the firstWaiter and lastWaiter. There's a race with unlinkCancelledWaiters() but according to @DougLea it should be a benign one. There's a performance impact of this, but as it is a plain write, and one to null at that, it should be acceptable. - Commit messages: - Minimizes the risk of AQS & AQLS waiter queues to be prematurely promoted to old gen Changes: https://git.openjdk.org/jdk/pull/17950/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17950&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8325754 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17950.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17950/head:pull/17950 PR: https://git.openjdk.org/jdk/pull/17950
Integrated: 8326351: Update the Zlib version in open/src/java.base/share/legal/zlib.md to 1.3.1
On Tue, 20 Feb 2024 19:56:53 GMT, Lance Andersen wrote: > Please review the updates to open/src/java.base/share/legal/zlib.md to update > the file from zlib 1.2.13 to zlib 1.3.1 which was missed as part of the PR > for [JDK-8324632](https://bugs.openjdk.org/browse/JDK-8324632) This pull request has now been integrated. Changeset: f0f4d63f Author:Lance Andersen URL: https://git.openjdk.org/jdk/commit/f0f4d63fa9c9f487198b2a2b7b410b590e1437bc Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8326351: Update the Zlib version in open/src/java.base/share/legal/zlib.md to 1.3.1 Reviewed-by: iris, naoto, jpai - PR: https://git.openjdk.org/jdk/pull/17935
Re: CFV: New Core Libraries Group Member: Viktor Klang
Vote: Yes On 20/02/2024 17:51, Naoto Sato wrote: Vote: yes Naoto On 2/19/24 3:40 PM, Stuart Marks wrote: I hereby nominate Viktor Klang [6] to Membership in the Core Libraries Group [4]. Viktor has been a member of the Java team in Oracle since 2022, and he is currently a Committer on the JDK project. Viktor has led JEP 461 [1], an enhancement to the Streams API to support new intermediate stream operations. Viktor has also contributed several other changes to the JDK [2][3], focusing primarily on the java.util.concurrent package. Prior to his work on OpenJDK, Viktor's past work includes Akka, Reactive Streams, and many other contributions to the Scala world. Votes are due by 23:59 UTC on March 4, 2024. Only current Members of the Core Libraries Group [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. s'marks [1] https://openjdk.org/jeps/461 [2] https://github.com/openjdk/jdk/commits?author=vklang%40openjdk.org [3] https://github.com/openjdk/jdk/commits?author=viktorklang-ora [4] https://openjdk.org/census#core-libs [5] https://openjdk.org/groups/#member-vote [6] https://openjdk.org/census#vklang
Re: RFR: 8326370: Remove redundant and misplaced micros from StringBuffers
On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad wrote: > Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem > out-of-place (not testing `StringBuffer`), redundant (covered by other tests > like StringSubstring or the various String concatenation tests), or both. > This cleans them out. > > My apologies to Sigurd. Thanks! - PR Comment: https://git.openjdk.org/jdk/pull/17937#issuecomment-1956432700
Integrated: 8326370: Remove redundant and misplaced micros from StringBuffers
On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad wrote: > Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem > out-of-place (not testing `StringBuffer`), redundant (covered by other tests > like StringSubstring or the various String concatenation tests), or both. > This cleans them out. > > My apologies to Sigurd. This pull request has now been integrated. Changeset: 5f16f342 Author:Claes Redestad URL: https://git.openjdk.org/jdk/commit/5f16f342d9be955b87054bf4b6369ed47cca964d Stats: 38 lines in 1 file changed: 0 ins; 38 del; 0 mod 8326370: Remove redundant and misplaced micros from StringBuffers Reviewed-by: shade - PR: https://git.openjdk.org/jdk/pull/17937
RFR: 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly
The implementation of the JVM TI `GetCurrentContendedMonitor` does not match the spec. It can sometimes return an incorrect information about the contended monitor. Such a behavior does not match the function spec. With this update the `GetCurrentContendedMonitor` is returning the monitor only when the specified thread is waiting to enter or re-enter the monitor, and the monitor is not returned when the specified thread is waiting in the `java.lang.Object.wait` to be notified. The implementation of the JDWP `ThreadReference.CurrentContendedMonitor` command is based and depends on this JVMTI function. The command was both specified incorrectly and had an incorrect behavior. The fix slightly corrects the JDWP spec to make it right (the JDWP implementation has been fixed by the JVM TI update). Please, see and review the related CSR and Release-Note. CSR: [8326024](https://bugs.openjdk.org/browse/JDK-8326024): JVM TI GetCurrentContendedMonitor is implemented incorrectly RN: [8326038](https://bugs.openjdk.org/browse/JDK-8326038): Release Note: JVM TI GetCurrentContendedMonitor is implemented incorrectly Testing: - tested with the mach5 tiers 1-6 - Commit messages: - 8256314: JVM TI GetCurrentContendedMonitor is implemented incorrectly Changes: https://git.openjdk.org/jdk/pull/17944/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17944&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8256314 Stats: 46 lines in 5 files changed: 27 ins; 10 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17944.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17944/head:pull/17944 PR: https://git.openjdk.org/jdk/pull/17944
Re: RFR: 8326370: Remove redundant and misplaced micros from StringBuffers
On Tue, 20 Feb 2024 20:58:50 GMT, Claes Redestad wrote: > Some microbenchmarks in org.openjdk.bench.java.lang.StringBuffers seem > out-of-place (not testing `StringBuffer`), redundant (covered by other tests > like StringSubstring or the various String concatenation tests), or both. > This cleans them out. > > My apologies to Sigurd. Marked as reviewed by shade (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/17937#pullrequestreview-1892606135
Re: RFR: 8311302: Allow for jlinking a custom runtime without packaged modules being present [v15]
On Tue, 23 Jan 2024 15:46:04 GMT, Severin Gehwolf wrote: >> Please review this patch which adds a jlink mode to the JDK which doesn't >> need the packaged modules being present. A.k.a run-time image based jlink. >> Fundamentally this patch adds an option to use `jlink` even though your JDK >> install might not come with the packaged modules (directory `jmods`). This >> is particularly useful to further reduce the size of a jlinked runtime. >> After the removal of the concept of a JRE, a common distribution mechanism >> is still the full JDK with all modules and packaged modules. However, >> packaged modules can incur an additional size tax. For example in a >> container scenario it could be useful to have a base JDK container including >> all modules, but without also delivering the packaged modules. This comes at >> a size advantage of `~25%`. Such a base JDK container could then be used to >> `jlink` application specific runtimes, further reducing the size of the >> application runtime image (App + JDK runtime; as a single image *or* >> separate bundles, depending on the app being modularized). >> >> The basic design of this approach is to add a jlink plugin for tracking >> non-class and non-resource files of a JDK install. I.e. files which aren't >> present in the jimage (`lib/modules`). This enables producing a `JRTArchive` >> class which has all the info of what constitutes the final jlinked runtime. >> >> Basic usage example: >> >> $ diff -u <(./bin/java --list-modules --limit-modules java.se) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules java.se) >> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) >> <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules >> --limit-modules jdk.jlink) >> $ ls ../linux-x86_64-server-release/images/jdk/jmods >> java.base.jmodjava.net.http.jmod java.sql.rowset.jmod >> jdk.crypto.ec.jmod jdk.internal.opt.jmod >> jdk.jdi.jmod jdk.management.agent.jmod jdk.security.auth.jmod >> java.compiler.jmodjava.prefs.jmod java.transaction.xa.jmod >> jdk.dynalink.jmod jdk.internal.vm.ci.jmod >> jdk.jdwp.agent.jmod jdk.management.jfr.jmodjdk.security.jgss.jmod >> java.datatransfer.jmodjava.rmi.jmodjava.xml.crypto.jmod >> jdk.editpad.jmod jdk.internal.vm.compiler.jmod >> jdk.jfr.jmod jdk.management.jmodjdk.unsupported.desktop.jmod >> java.desktop.jmod java.scripting.jmod java.xml.jmod >> jdk.hotspot.agent.jmod jdk.i... > > Severin Gehwolf has updated the pull request incrementally with one > additional commit since the last revision: > > Rename singleHop field. I'm working on an update. Please keep open. - PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-1956190334
