The fix deprecates -XX:+UseNotificationThread VM option
Testing: tier1-3
-
Commit messages:
- fix
Changes: https://git.openjdk.org/jdk/pull/18852/files
Webrev: https://webrevs.openjdk.org/?repo=jdk=18852=00
Issue: https://bugs.openjdk.org/browse/JDK-8329113
Stats: 3 lines in
The fix updates HeapMerger to use writer buffer (no need to copy memory, also
writer buffer is 1MB instead of 4KB).
Additionally fixed small issue in FileWriter (looks like `ssize_t` instead of
`size_t` is a typo, the argument should be unsigned)
Testing: all HeapDump-related tests on Oracle
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
> This is the test issue. The `WaitingPT3` thread posted the `MonitorWait`
> event but has not released the `lockCheck` monitor yet. It has been fixed to
> wait for each `WaitingTask` thread to really reach the `WAITING` state. The
> same approach is used for `EnteringTask` threads. It has been
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
> Please review the updates to support a proposed new
> `-Xlint:dangling-doc-comments` option.
>
> The work can be thought of as in 3 parts:
>
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it
> is possible to specify the appropriately configured `Lint` object when
On 4/18/24 2:54 AM, Severin Gehwolf wrote:
On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
IMHO `is_containerized()` is OK to return `false` even when running in a
container but with no limitations set.
The idea here is to use this property to tune OpenJDK for in-container,
On 4/18/24 9:38 AM, Severin Gehwolf wrote:
On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
Could not we rename `is_containerized()` to `use_container_limit()` ? As that
is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()`
On Thu, 18 Apr 2024 13:27:38 GMT, Jan Kratochvil
wrote:
> Could not we rename `is_containerized()` to `use_container_limit()` ? As that
> is the current only purpose of `is_containerized()`.
I'm not sure. There is value to have `is_containerized()` like it would behave
after this patch.
On Wed, 17 Apr 2024 22:41:08 GMT, Dean Long wrote:
>> Matias Saavedra Silva has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Dean and Gilles comments
>
> src/hotspot/share/ci/ciEnv.cpp line 1513:
>
>> 1511: // process the BSM
>>
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> operands needed to be rewritten to encoded values to better distinguish indy
>
On Wed, 17 Apr 2024 22:48:16 GMT, Dean Long wrote:
> Did you consider minimizing changes by leaving
> decode_invokedynamic_index/encode_invokedynamic_index calls in place, but
> having the implementations not change the value?
The intention from the start was to remove the encode/decode
On Wed, 17 Apr 2024 22:43:38 GMT, Dean Long wrote:
>> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
>> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
>> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
>> operands needed to be
On Thu, 18 Apr 2024 00:41:03 GMT, Vladimir Kozlov wrote:
>> This is part of changes which try to reduce size of `nmethod` and `codeblob`
>> data vs code in CodeCache.
>> These changes reduced size of `nmethod` header from 288 to 232 bytes. From
>> 304 to 248 in optimized VM:
>>
>> Statistics
On Thu, 11 Apr 2024 12:08:02 GMT, Severin Gehwolf wrote:
>> Please review this enhancement to the container detection code which allows
>> it to figure out whether the JVM is actually running inside a container
>> (`podman`, `docker`, `crio`), or with some other means that enforces
>>
On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva
wrote:
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> operands needed
On Wed, 17 Apr 2024 01:07:04 GMT, Jan Kratochvil
wrote:
>>> IMHO `is_containerized()` is OK to return `false` even when running in a
>>> container but with no limitations set.
>>
>> The idea here is to use this property to tune OpenJDK for in-container,
>> specifically k8s, use. In such a
On Wed, 17 Apr 2024 22:58:21 GMT, Dean Long wrote:
> @dougxc should check JVMCI changes.
Thanks for the heads up. I've asked @matias9927 to double check these changes
against libgraal which should address any concerns about how this change
impacts Graal.
-
PR Comment:
On Wed, 17 Apr 2024 15:26:52 GMT, Matias Saavedra Silva
wrote:
> Before [JDK-8307190](https://bugs.openjdk.org/browse/JDK-8307190),
> [JDK-8309673](https://bugs.openjdk.org/browse/JDK-8309673), and
> [JDK-8301995](https://bugs.openjdk.org/browse/JDK-8301995), invokedynamic
> operands needed
19 matches
Mail list logo