On Fri, 28 Oct 2022 15:28:42 GMT, Roman Kennke wrote:
>> There are several users and even mostly-identical implementations of
>> Threads::owning_thread_from_monitor_owner(), which I would like to
>> consolidate a little in preparation of JDK-8291555:
>> - JvmtiEnvBase::get_monitor_usage(): As t
On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism defin
On Fri, 28 Oct 2022 15:28:42 GMT, Roman Kennke wrote:
>> There are several users and even mostly-identical implementations of
>> Threads::owning_thread_from_monitor_owner(), which I would like to
>> consolidate a little in preparation of JDK-8291555:
>> - JvmtiEnvBase::get_monitor_usage(): As t
On Tue, 25 Oct 2022 11:39:37 GMT, Roman Kennke wrote:
> There are several users and even mostly-identical implementations of
> Threads::owning_thread_from_monitor_owner(), which I would like to
> consolidate a little in preparation of JDK-8291555:
> - JvmtiEnvBase::get_monitor_usage(): As the c
On Fri, 28 Oct 2022 15:15:15 GMT, Daniel D. Daugherty
wrote:
>>> This is nice simplification. It looks pretty good. To be more safe, I'd
>>> suggest to run tier5 as well. Thanks, Serguei
>>
>> AFAIK, there is no tier5 (in OpenJDK). If you have something internal, then
>> please give it a spin
On Fri, 28 Oct 2022 15:28:42 GMT, Roman Kennke wrote:
>> There are several users and even mostly-identical implementations of
>> Threads::owning_thread_from_monitor_owner(), which I would like to
>> consolidate a little in preparation of JDK-8291555:
>> - JvmtiEnvBase::get_monitor_usage(): As t
On Fri, 28 Oct 2022 01:04:57 GMT, Chris Plummer wrote:
> Fix typo: "and and" => "and"
This pull request has now been integrated.
Changeset: 1c86cf55
Author:Chris Plummer
URL:
https://git.openjdk.org/jdk/commit/1c86cf5507a3126a00052d8c2d13c8fdc6e1da55
Stats: 1 line in 1 file chan
This is a question for the gc team, so please use hotspot-gc-...@openjdk.org
thanks,
Chris
On 10/27/22 11:33 PM, 地上的月影 wrote:
Hi,
while working with openjdk11, the JDK-8207200 problem happens
to me，there is a certain probability that the prolem will occur and shows "Cannot determine current
On Fri, 28 Oct 2022 14:54:26 GMT, Daniel Fuchs wrote:
>> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
>> to parse or construct any URL.
>>
>> The `java.net.URL` class does not itself encode or decode any URL components
>> according to the escaping mechanism defin
On Fri, 28 Oct 2022 09:32:58 GMT, Roman Kennke wrote:
>> This change replaces the current stack-locking implementation with a
>> fast-locking scheme that retains the advantages of stack-locking (namely
>> fast locking in uncontended code-paths), while avoiding the overload of the
>> mark word.
On Fri, 28 Oct 2022 09:18:28 GMT, Roman Kennke wrote:
>> This is nice simplification.
>> It looks pretty good.
>> To be more safe, I'd suggest to run tier5 as well.
>> Thanks,
>> Serguei
>
>> This is nice simplification. It looks pretty good. To be more safe, I'd
>> suggest to run tier5 as well.
> There are several users and even mostly-identical implementations of
> Threads::owning_thread_from_monitor_owner(), which I would like to
> consolidate a little in preparation of JDK-8291555:
> - JvmtiEnvBase::get_monitor_usage(): As the comment in
> ObjectSynchronizer::get_lock_owner() sugges
On Fri, 28 Oct 2022 09:18:28 GMT, Roman Kennke wrote:
>> This is nice simplification.
>> It looks pretty good.
>> To be more safe, I'd suggest to run tier5 as well.
>> Thanks,
>> Serguei
>
>> This is nice simplification. It looks pretty good. To be more safe, I'd
>> suggest to run tier5 as well.
> Deprecate URL constructors. Developers are encouraged to use `java.net.URI`
> to parse or construct any URL.
>
> The `java.net.URL` class does not itself encode or decode any URL components
> according to the escaping mechanism defined in RFC2396. It is the
> responsibility of the caller to e
On Thu, 27 Oct 2022 10:58:12 GMT, Roman Kennke wrote:
>> There are several users and even mostly-identical implementations of
>> Threads::owning_thread_from_monitor_owner(), which I would like to
>> consolidate a little in preparation of JDK-8291555:
>> - JvmtiEnvBase::get_monitor_usage(): As t
> This change replaces the current stack-locking implementation with a
> fast-locking scheme that retains the advantages of stack-locking (namely fast
> locking in uncontended code-paths), while avoiding the overload of the mark
> word. That overloading causes massive problems with Lilliput, bec
On Fri, 28 Oct 2022 00:16:34 GMT, Serguei Spitsyn wrote:
> This is nice simplification. It looks pretty good. To be more safe, I'd
> suggest to run tier5 as well. Thanks, Serguei
AFAIK, there is no tier5 (in OpenJDK). If you have something internal, then
please give it a spin?
Thanks,
Roman
17 matches
Mail list logo
