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
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 upd
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.openj
> 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
o
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
> 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
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 (computeNex
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.
>>
> 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:
> - `Refer
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:
> 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 updat
> 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). A
> 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 su
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
>> Ho
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
> HotSpot
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 r
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 acc
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 chan
> 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
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
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.fai
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 unlinkCancelledWa
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 reque
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 th
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 cle
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 cle
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
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 cle
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
>>
29 matches
Mail list logo
