snprintf has been available for all officially and unofficially supported
compilers for Windows, Visual Studio since version 2015 and gcc since, well,
forever. snprintf is conforming to C99 since the start when compiling using
gcc, and 2015 when using Visual Studio. Since it conforms to C99 and
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
Small corrections to @implSpec notes in a few methods in RandomGenerator.
-
Commit messages:
- 8334758: Incorrect note in Javadoc for a few RandomGenerator methods
Changes: https://git.openjdk.org/jdk/pull/20152/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20152&range=00
> When inflating a monitor the `ObjectMonitor*` is written directly over the
> `markWord` and any overwritten data is displaced into a displaced `markWord`.
> This is problematic for concurrent GCs which needs extra care or looser
> semantics to use this displaced data. In Lilliput this data als
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
On Thu, 11 Jul 2024 20:55:29 GMT, Nizar Benalla wrote:
> Can I please get a review for this small change, the relative link to the
> stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
> correct link to the stylesheet is already in the generated HTML.
>
> This is the di
On Tue, 9 Jul 2024 12:07:37 GMT, Galder Zamarreño wrote:
> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
> order to help improve vectorization performance.
>
> Currently vectorization does not kick in for loops containing either of these
> calls because of the fo
On Thu, 11 Jul 2024 23:17:10 GMT, Vladimir Ivanov wrote:
>> This patch expands the use of a hash table for secondary superclasses
>> to the interpreter, C1, and runtime. It also adds a C2 implementation
>> of hashed lookup in cases where the superclass isn't known at compile
>> time.
>>
>> HotSp
On Tue, 2 Jul 2024 14:52:09 GMT, Andrew Haley wrote:
> This patch expands the use of a hash table for secondary superclasses
> to the interpreter, C1, and runtime. It also adds a C2 implementation
> of hashed lookup in cases where the superclass isn't known at compile
> time.
>
> HotSpot shared
On Tue, 9 Jul 2024 21:16:33 GMT, Claes Redestad wrote:
>> This PR attains a speed-up on some microbenchmarks by simplifying how we
>> build up the MH combinator tree shape
>> (only use prependers with prefix, always add a suffix to the newArray
>> combinator), then simplifying/inlining some of
On Tue, 9 Jul 2024 12:07:37 GMT, Galder Zamarreño wrote:
> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in
> order to help improve vectorization performance.
>
> Currently vectorization does not kick in for loops containing either of these
> calls because of the fo
On Thu, 11 Jul 2024 20:31:07 GMT, Stuart Marks wrote:
> Bloch's _Effective Java, 3/e,_ Items 10, 11, and 12 have some useful
> background information on implementing equals, hashCode, and toString.
Agreed; I reread over those items before posting the PR.
The "typical" wording was meant to cove
On Thu, 11 Jul 2024 00:06:33 GMT, Stuart Marks wrote:
> While it's not wrong, advising against "excessive" usage is so vague as not
> to be actionable. Given some piece of code it's hard to say whether or not it
> does anything excessive. Consider a List with a million elements; as a
> practic
On Tue, 4 Jun 2024 07:13:15 GMT, Vanitha B P wrote:
> Created jtreg test case for
> [JDK-8325203](https://bugs.openjdk.org/browse/JDK-8325203) issue.
>
> The JpackageTest created tests that the child process started from the app
> launched by jpackage launcher is not automatically terminated w
On Wed, 1 May 2024 22:39:05 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 upda
On Wed, 29 May 2024 19:27:17 GMT, Chen Liang wrote:
>> I propose to add type-checked ConstantPool.entryByIndex and
>> ClassReader.readEntryOrNull taking an extra Class parameter, which throws
>> ConstantPoolException instead of ClassCastException on type mismatch, which
>> can happen to malfor
On Sun, 12 May 2024 08:36:44 GMT, Chen Liang wrote:
> Some tests are not migrated to the ClassFile API in previous migrations.
>
> - Some are simple oversights that didn't remove usages of
> com.sun.tools.classfile;
> - The CallerSensitive ones used an old utility, replaced by CF API-based ne
On Sun, 12 May 2024 02:42:32 GMT, Chen Liang wrote:
>> Summary of the changes:
>> - Moved `com.sun.tools.classfile.Dependency` and `Dependencies` to jdeps;
>> they are exclusively used by jdeps in sources, and they are not used in any
>> tests too. This will ease the removal of `com.sun.tools.
On Fri, 10 May 2024 04:55:21 GMT, Chen Liang wrote:
>> GenerateJLIClassesHelper has been making wrong assumptions about Invoker's
>> LambdaForm method type parameters. Since they are distinct from those of
>> Linkers, they are now tracked and generated separately. It seems that no
>> proper in
On Fri, 7 Jun 2024 13:56:24 GMT, Chen Liang wrote:
>> In java.base, especially in bytecode generators, we have many different
>> methods converting known valid Class and MethodType into ClassDesc and
>> MethodTypeDesc. These conversions should be consolidated into the same
>> utility method fo
Can I please get a review for this small change, the relative link to the
stylesheet isn't needed as it wasn't used anyway in the generated HTML. The
correct link to the stylesheet is already in the generated HTML.
This is the difference between the generated docs before and after this change,
On Wed, 10 Jul 2024 22:10:50 GMT, Chen Liang wrote:
> Please review this non-clean backport of the bugfix in #20100 to release 23,
> where ClassFile API chained builders does not emit certain elements through
> downstream transforms and returns wrong builder for chaining. This backport
> inclu
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote:
> First pass at adding some quality of implementation discussions around the
> overridable methods of Object.
Bloch's _Effective Java, 3/e,_ Items 10, 11, and 12 have some useful background
information on implementing equals, hashCode, and toS
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 performance
> s
[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
Moved to loom-dev; core-libs-dev to bcc.
On Tue, Jul 9, 2024 at 12:10 PM Alan Bateman
wrote:
> Probably best to bring this to loom-dev as there have been some
> exploration into but where we decided not to expose any APIs at this time.
>
> -Alan
>
> On 09/07/2024 19:50, Louis Wasserman wrote:
>
On Tue, 9 Jul 2024 18:42:25 GMT, Justin Lu wrote:
> Please review this PR which corrects a case in NumberFormat integer only
> parsing.
>
> [JDK-8333755](https://bugs.openjdk.org/browse/JDK-8333755) fixed integer only
> parsing when the value has a suffix, although it caused incorrect behavior
On Wed, 10 Jul 2024 16:24:01 GMT, Joe Wang wrote:
> Remove valign Attribute from the javadoc for org.w3c.dom.Attr. The table
> looks good with the default setting.
This pull request has now been integrated.
Changeset: 58c98420
Author:Joe Wang
URL:
https://git.openjdk.org/jdk/commit
On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote:
> Please review this PR, which is a backport of commit
> [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> This updates the IANA sub
On Wed, 10 Jul 2024 22:08:47 GMT, Justin Lu wrote:
> Please review this PR, which is a backport of commit
> [86b0cf25](https://github.com/openjdk/jdk/commit/86b0cf259fb3cbe3a1973151148e5d36c6a99d91)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> This change incorporates
On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote:
> File.mkdirs() occasionally fails to create folders on Windows shared folders.
> It turned out that Windows API FindFirstFileW created the error
> ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error
> still returns
On Thu, 11 Jul 2024 16:46:13 GMT, Severin Gehwolf wrote:
>> Please review this PR which adds test support for systemd slices so that
>> bugs like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be
>> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on
>> c
> Please review this PR which adds test support for systemd slices so that bugs
> like [JDK-8217338](https://bugs.openjdk.org/browse/JDK-8217338) can be
> verified. The added test, `SystemdMemoryAwarenessTest` currently passes on
> cgroups v1 and fails on cgroups v2 due to the way how
> [JDK-82
On Wed, 12 Jun 2024 02:00:41 GMT, SendaoYan wrote:
> Hi all,
> Currently, the testcase `test/jdk/tools/jlink/JLinkReproducibleTest.java`
> doesn't receive jvm options from jtreg.
> I think it's necessory to receive jvm options from jtreg.
> Fix solution similar to
> [JDK-8157850](https://bugs.o
On Wed, 10 Jul 2024 22:33:54 GMT, Joe Darcy wrote:
> First pass at adding some quality of implementation discussions around the
> overridable methods of Object.
Here's a classical example of a directed acyclic graph (DAG, no cycles)
consisting of 100 `ArrayList`s, each of size 2.
It takes some
On Thu, 11 Jul 2024 14:26:23 GMT, Jan Kratochvil
wrote:
> > > ```
> > > * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it
> > > properly distributes the load but JDK still sees all available CPU cores
> > > (4 of my VM).
> > > ```
> >
> >
> > Could you elaborate on that? W
On Thu, 11 Jul 2024 09:23:58 GMT, Severin Gehwolf wrote:
> > ```
> > * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it
> > properly distributes the load but JDK still sees all available CPU cores (4
> > of my VM).
> > ```
>
> Could you elaborate on that? What does not work?
On Wed, 10 Jul 2024 21:46:36 GMT, Justin Lu wrote:
> Please review this PR, which is a backport of commit
> [861aefca](https://github.com/openjdk/jdk/commit/861aefcafacdc21459ef966307f52568e327fd49)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> This updates the IANA sub
On Wed, 10 Jul 2024 09:41:37 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/lightweightSynchronizer.cpp line 763:
>>
>>> 761: assert(mark.has_monitor(), "must be");
>>> 762: // The monitor exists
>>> 763: ObjectMonitor* monitor = ObjectSynchronizer::read_monitor(current,
>
On Fri, 3 Nov 2023 18:11:10 GMT, Weibing Xiao wrote:
> File.mkdirs() occasionally fails to create folders on Windows shared folders.
> It turned out that Windows API FindFirstFileW created the error
> ERROR_NO_MORE_FILES. In some of the cases with a valid file path, this error
> still returns
On Wed, 10 Jul 2024 09:41:08 GMT, Axel Boldt-Christmas
wrote:
>> src/hotspot/share/runtime/arguments.cpp line 1830:
>>
>>> 1828: FLAG_SET_CMDLINE(LockingMode, LM_LIGHTWEIGHT);
>>> 1829: warning("UseObjectMonitorTable requires LM_LIGHTWEIGHT");
>>> 1830: }
>>
>> Maybe we want this to
On Thu, 11 Jul 2024 06:54:27 GMT, Jan Kratochvil
wrote:
>> The testcase requires root permissions.
>>
>> Designed by Severin Gehwolf, implemented by Jan Kratochvil.
>
> Jan Kratochvil has updated the pull request with a new target base due to a
> merge or a rebase. The pull request now contai
On Wed, 10 Jul 2024 17:01:00 GMT, Jorn Vernee wrote:
> Hi all,
>
> This pull request contains a backport of commit
> [6f7f0f1d](https://github.com/openjdk/jdk/commit/6f7f0f1de05fdc0f6a88ccd90b806e8a5c5074ef)
> from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
>
> The commit bein
On Thu, 11 Jul 2024 09:25:52 GMT, Yudi Zheng wrote:
>> Axel Boldt-Christmas has updated the pull request incrementally with four
>> additional commits since the last revision:
>>
>> - Add extra comments in LightweightSynchronizer::inflate_fast_locked_object
>> - Fix typos
>> - Remove unused
On Thu, 11 Jul 2024 09:36:02 GMT, Pavel Rappo wrote:
> Was reading Process' documentation the other day and spotted a markup typo.
> Please review this utmost trivial fix.
This pull request has now been integrated.
Changeset: 6fcd49f9
Author:Pavel Rappo
URL:
https://git.openjdk.org
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 contains six additional
>> comm
On Thu, 11 Jul 2024 09:36:02 GMT, Pavel Rappo wrote:
> Was reading Process' documentation the other day and spotted a markup typo.
> Please review this utmost trivial fix.
Marked as reviewed by jpai (Reviewer).
-
PR Review: https://git.openjdk.org/jdk/pull/20133#pullrequestreview-
Was reading Process' documentation the other day and spotted a markup typo.
Please review this utmost trivial fix.
-
Commit messages:
- Initial commit
Changes: https://git.openjdk.org/jdk/pull/20133/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20133&range=00
Issue: ht
On Wed, 10 Jul 2024 20:10:07 GMT, Axel Boldt-Christmas
wrote:
>> When inflating a monitor the `ObjectMonitor*` is written directly over the
>> `markWord` and any overwritten data is displaced into a displaced
>> `markWord`. This is problematic for concurrent GCs which needs extra care or
>> l
On Thu, 11 Jul 2024 03:42:27 GMT, Jan Kratochvil
wrote:
> [test.patch.txt](https://github.com/user-attachments/files/16171122/test.patch.txt)
>
> * `CPUQuota` (changed it to `AllowedCPUs`) does not work for me - it
> properly distributes the load but JDK still sees all available CPU cores
On Thu, 11 Jul 2024 03:39:37 GMT, Jan Kratochvil
wrote:
>> Severin Gehwolf 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 four additional
>> c
On Mon, 8 Jul 2024 19:01:05 GMT, Doug Simon wrote:
> This PR addresses intermittent failures in jtreg GC stress tests. The
> failures occur under these conditions:
> 1. Using a libgraal build with assertions enabled as the top tier JIT
> compiler. Such a libgraal build will cause a VM exit if a
On Tue, 9 Jul 2024 13:46:46 GMT, Doug Simon wrote:
>> This PR addresses intermittent failures in jtreg GC stress tests. The
>> failures occur under these conditions:
>> 1. Using a libgraal build with assertions enabled as the top tier JIT
>> compiler. Such a libgraal build will cause a VM exit
On Wed, 10 Jul 2024 22:10:50 GMT, Chen Liang wrote:
> Please review this non-clean backport of the bugfix in #20100 to release 23,
> where ClassFile API chained builders does not emit certain elements through
> downstream transforms and returns wrong builder for chaining. This backport
> inclu
55 matches
Mail list logo
