On Fri, 11 Sep 2020 01:08:53 GMT, Daniil Titov wrote:
> The change fixes the regression introduced by
> https://bugs.openjdk.java.net/browse/JDK-8241080.
>
> Method validateAssignment() in com.sun.tools.jdi.ObjectReferenceImpl now
> always retrieves the reference type and that
> requires one m
On Fri, 11 Sep 2020 03:31:54 GMT, David Holmes wrote:
>> What do you think about moving
>> Handle obj = ThreadService::get_current_contended_monitor(thread);
>> out of scope of block_object oop visibility?
>> It is my second patch.
>
> I'm missing something. How can a NULL oop get corrupted e
On Fri, 11 Sep 2020 02:53:51 GMT, Leonid Mesnik wrote:
>> It is not loom-specific and reproduced n jdk/jdk with
>> -XX:+CheckUnhandledOops.
>
> What do you think about moving
> Handle obj = ThreadService::get_current_contended_monitor(thread);
> out of scope of block_object oop visibility?
>
On Fri, 11 Sep 2020 02:52:15 GMT, Leonid Mesnik wrote:
>> I can't see anywhere a safepoint check would occur in that code. This issue
>> was flagged as being in Loom so perhaps the
>> loom code is different and is what introduces the safepoint check? But I
>> agree with Coleen that the best sol
On Fri, 11 Sep 2020 02:49:04 GMT, David Holmes wrote:
>> src/hotspot/share/services/threadService.cpp line 888:
>>
>>> 886: _thread_status == java_lang_Thread::IN_OBJECT_WAIT_TIMED) {
>>> 887:
>>> 888: Handle obj = ThreadService::get_current_contended_monitor(thread);
>>
>> There must
On Fri, 11 Sep 2020 02:53:51 GMT, Leonid Mesnik wrote:
>> The NULL oops are corrupted by CheckUnhandledOops and should be re-written
>> with NULL to pass testing
>> with -XX:+CheckUnhandledOops.
>
> Leonid Mesnik has updated the pull request incrementally with one additional
> commit since the
> The NULL oops are corrupted by CheckUnhandledOops and should be re-written
> with NULL to pass testing
> with -XX:+CheckUnhandledOops.
Leonid Mesnik has updated the pull request incrementally with one additional
commit since the last revision:
8253033: CheckUnhandledOops check fails in Thre
On Fri, 11 Sep 2020 00:19:47 GMT, Coleen Phillimore wrote:
>> Leonid Mesnik has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> 8253033: CheckUnhandledOops check fails in ThreadSnapshot::initialize(...)
>
> src/hotspot/share/services/threadS
On Mon, 7 Sep 2020 05:56:14 GMT, David Holmes wrote:
> This is a rather large but generally simple cleanup.
>
> We use a lot of raw C-style casts to "(JavaThread*)" typically after checking
> "thread->is_Java_thread()". To simplify
> this pattern, and make the code look somewhat cleaner we intr
The change fixes the regression introduced by
https://bugs.openjdk.java.net/browse/JDK-8241080.
Method validateAssignment() in com.sun.tools.jdi.ObjectReferenceImpl now always
retrieves the reference type and that
requires one more JDWP packet if the value is not cached yet. Before
https://bugs
On Sat, 5 Sep 2020 14:26:17 GMT, Yasumasa Suenaga wrote:
> If `Agent_OnAttach()` in JVMTI agent which is attempted to load via
> JVMTI.agent_load dcmd is failed, it would not be
> unloaded. We've [discussed it on
> serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/
If `Agent_OnAttach()` in JVMTI agent which is attempted to load via
JVMTI.agent_load dcmd is failed, it would not be
unloaded. We've [discussed it on
serviceability-dev](https://mail.openjdk.java.net/pipermail/serviceability-dev/2020-September/032839.html).
This PR is
a continuation of that.
T
On Thu, 10 Sep 2020 23:38:45 GMT, Leonid Mesnik wrote:
> The NULL oops are corrupted by CheckUnhandledOops and should be re-written
> with NULL to pass testing
> with -XX:+CheckUnhandledOops.
Changes requested by coleenp (Reviewer).
src/hotspot/share/services/threadService.cpp line 888:
> 886
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
1) This is un-necessary churn.
2) I can't
On Thu, 10 Sep 2020 12:04:48 GMT, Dmitriy Dumanskiy
wrote:
> I have in mind dozens of improvements all over the code like this one.
That sounds scary. Broad updates like these cause unnecessary churn in the
codebase, and can make merging and back
porting harder. Changes should be discussed ah
On Thu, 10 Sep 2020 15:50:39 GMT, Alan Bateman wrote:
>> 14 cc'd mailing lists is unworkable. You need to be subscribed to lists to
>> post, but even if you are a reply-all will
>> be delayed due to all of the mails being held up for moderator approval due
>> to:
>> " Too many recipients to the
On Thu, 10 Sep 2020 13:53:10 GMT, David Holmes wrote:
>> @dholmes-ora raises a good point. Hopefully there is a balance point between
>> a dozen different bugs / pull requests
>> each targeting one area and one bug / PR targeting a dozen separate areas. I
>> don't have a good general rule to su
Also this fix needs to be reviewed by the Serviceability team.
I've moved hotspot-dev@... to Bcc and added serviceability-dev@...
Dan
On 9/10/20 5:53 AM, Severin Gehwolf wrote:
Hi Adam,
jdk/jdk moved to skara[1]. Please re-create the patch as a github PR
(or with the skara CLI tooling).
Than
On Thu, 10 Sep 2020 03:18:23 GMT, David Holmes wrote:
>> This is a rather large but generally simple cleanup.
>>
>> We use a lot of raw C-style casts to "(JavaThread*)" typically after
>> checking "thread->is_Java_thread()". To simplify
>> this pattern, and make the code look somewhat cleaner w
On 10/09/2020 10:07 pm, Dmitriy Dumanskiy wrote:
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
The code in java.base was updated to use String::isEmpty in JDK 12
(JDK-8215281). There was follow-up in JDK 13 to do
the same in the java.desktop module (JDK-8223237). Changing the remainin
On Thu, 10 Sep 2020 12:18:51 GMT, Kevin Rushforth wrote:
>> This should be broken up to deal with the files in different functional
>> areas under different bugids and PRs. Otherwise
>> the cross-posting to so many lists is prohibitive. Files in different areas
>> need to be reviewed by differe
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
>> The code in java.base was updated to use String::isEmpty in JDK 12
>> (JDK-8215281). There was follow-up in JDK 13 to do
>> the same in the java.desktop module (JDK-8223237). Changing the remaining
>> usages make sense although I see that
On Thu, 10 Sep 2020 11:21:28 GMT, David Holmes wrote:
>> The code in java.base was updated to use String::isEmpty in JDK 12
>> (JDK-8215281). There was follow-up in JDK 13 to do
>> the same in the java.desktop module (JDK-8223237). Changing the remaining
>> usages make sense although I see that
On Thu, 10 Sep 2020 10:40:15 GMT, Alan Bateman wrote:
>> @kevinrushforth thanks. Done.
>>
>> Similar issues:
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8215014
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8251246
>> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=822
On Thu, 10 Sep 2020 08:47:35 GMT, Dmitriy Dumanskiy
wrote:
>> Before this Enhancement can be formally reviewed, you will need a JBS bug
>> ID. If you are already working with a
>> Committer or Reviewer in the `jdk` project who has agreed to sponsor your
>> change, they can file the Enhancement
On Thu, 10 Sep 2020 09:33:28 GMT, Per Lidén wrote:
>> - enable parallel heap inspection for ZCollectedHeap
>> - preliminary evaluation:
>> Time of jmap histo on 8GB heap with ~5GB objects
>> * before: 7.103s
>> * after : 2.734s (with 4 parallel threads)
>
> Just looked at this briefly. My i
On Thu, 10 Sep 2020 02:28:43 GMT, Lin Zang wrote:
> - enable parallel heap inspection for ZCollectedHeap
> - preliminary evaluation:
> Time of jmap histo on 8GB heap with ~5GB objects
> * before: 7.103s
> * after : 2.734s (with 4 parallel threads)
Just looked at this briefly. My initial co
On Wed, 9 Sep 2020 20:21:44 GMT, Kevin Rushforth wrote:
>> @mrserb hello. Thanks for the review. Any further actions required from me?
>
> Before this Enhancement can be formally reviewed, you will need a JBS bug ID.
> If you are already working with a
> Committer or Reviewer in the `jdk` projec
On Wed, 9 Sep 2020 07:57:48 GMT, Dmitriy Dumanskiy
wrote:
>> @doom369 jcheck requires an associated issue
>
> @mrserb hello. Thanks for the review. Any further actions required from me?
Before this Enhancement can be formally reviewed, you will need a JBS bug ID.
If you are already working wit
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
src/demo/share/java2d/J2DBench/src/j2dben
On Sun, 6 Sep 2020 18:08:15 GMT, thatsIch
wrote:
>> **isEmpty** is faster + has less byte code + easier to read. Benchmarks
>> could be found
>>
>> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
>
> @doom369 jcheck requires an associated issu
On Sun, 6 Sep 2020 13:57:19 GMT, Dmitriy Dumanskiy
wrote:
> **isEmpty** is faster + has less byte code + easier to read. Benchmarks could
> be found
>
> [here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
@doom369 jcheck requires an associated is
**isEmpty** is faster + has less byte code + easier to read. Benchmarks could
be found
[here](https://medium.com/javarevisited/micro-optimizations-in-java-string-equals-22be19fd8416).
-
Commit messages:
- Merge branch 'master' of https://github.com/doom369/jdk into
reaplce_equal
33 matches
Mail list logo
