Hi Serguei,
I will put it on hold as David asked but before doing so I just wanted to give
a quick reply to the questions you asked.
Thanks!
Best regards,
Daniil
From: "serguei.spit...@oracle.com"
Date: Monday, July 8, 2019 at 3:09 PM
To: Daniil Titov , OpenJDK Serviceabili
Thank you Chris!
Serguei, do you agree with this change?
http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.07/
If you are ok, I will reopen the CSR (JDK-8224979).
http://mail.openjdk.java.net/pipermail/serviceability-dev/2019-July/028624.html
Thanks,
Yasumasa
On 2019/07/09 8:08,
> On Jul 8, 2019, at 7:00 PM, Kim Barrett wrote:
>Copy::disjoint_words_atomic(const HeapWord* from,volatile HeapWord* to,
> size_t count)
Or maybe
Copy::disjoint_words_atomic(const volatile HeapWord* from, volatile
HeapWord* to, size_t count)
Hi David,
Sure, I will put it on hold till you are back from the vacations.
Webrev: https://cr.openjdk.java.net/~dtitov/8170299/webrev.02/
Bug: https://bugs.openjdk.java.net/browse/JDK-8170299
Have a nice vacations!
Best regards,
Daniil
On 7/3/19, 11:47 PM, "David Holmes" wrote:
Hi D
Looks good! Sorry about the high number of iterations. I should have
caught some things sooner.
thanks,
Chris
On 7/8/19 3:43 PM, Yasumasa Suenaga wrote:
Hi Chris,
Thank you for your comment.
I fixed it in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.07/
Could you c
> On Jul 6, 2019, at 9:53 AM, Daniel D. Daugherty
> wrote:
>
> Greetings,
>
> During the code review for the following fix:
>
> JDK-8227117 normal interpreter table is not restored after single
> stepping with TLH
> https://bugs.openjdk.java.net/browse/JDK-8227117
>
> Erik O. noticed
> On Jul 7, 2019, at 8:08 PM, David Holmes wrote:
>
> On 7/07/2019 6:48 pm, Erik Osterlund wrote:
>> The real danger is SPARC though and its BIS instructions. I don’t have the
>> code in front of me, but I really hope not to see that switch statement and
>> non-volatile loop in that pd_disjoint
Hi Chris,
Thank you for your comment.
I fixed it in new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.07/
Could you check again?
Yasumasa
On 2019/07/09 4:11, Chris Plummer wrote:
Hi Yasumasa,
Sorry, just noticed one other thing:
<--core --exe> and <--pid> and <--c
On 6/29/19 12:06 PM, Daniil Titov wrote:
Hi Serguei and David,
Serguei is right, ThreadTable::find_thread(java_tid) cannot return a
JavaThread with an unmatched java_tid.
Please find a new version of the fix that includes the changes Serguei
suggested.
Regarding the concern about the mainta
Hi Daniil,
Did you see a message from David Holmes?
I do not see your reply.
Specifically, David asked to hold on with this while he is on
vacation for two weeks:
> But introducing a new thread in the VM also has the same set
of co
Hi Yasumasa,
Sorry, just noticed one other thing:
<--core --exe> and <--pid> and <--connect> are mutually exclusive.
I'm not sure why you are using angled brackets here. It's not done in
other parts of the help output that reference options by name. Also, no
need to mention --exe since th
Hi Serguei,
Please review the new version of the fix that corrects the order of include
statements in src/hotspot/share/runtime/notificationThread.cpp.
The list of Include statements doesn't contain "#include
"runtime/mutexLocker.hpp" since this include file is already included by
runtime/in
On 7/8/19 11:42 AM, Daniel D. Daugherty wrote:
Added back serviceability-dev@...
Coleen, please double check before using reply-to-list... if there's more
than one list, that feature doesn't work right...
Sometimes Reply-All in my mailer gets all the lists and sometimes it
doesn't. I'll c
Added back serviceability-dev@...
Coleen, please double check before using reply-to-list... if there's more
than one list, that feature doesn't work right...
On 7/8/19 11:34 AM, Daniel D. Daugherty wrote:
On 7/8/19 11:30 AM, coleen.phillim...@oracle.com wrote:
The change and comment look good
Hi David,
On 7/7/19 8:08 PM, David Holmes wrote:
On 7/07/2019 6:48 pm, Erik Osterlund wrote:
Yeah that switch statement code and yet another plain non-volatile
load/store loop looks like complete nonsense unfortunately. It should
at least use Atomic::load/store.
Fortunately, on x86_64, I bel
Thanks for the review Serguei.
Dan
On 7/8/19 7:28 AM, serguei.spit...@oracle.com wrote:
Hi Dan,
This looks good to me as far as just discussed the atomic copy is
considered to be a separate issue.
Thanks,
Serguei
On 7/6/19 06:53, Daniel D. Daugherty wrote:
Greetings,
During the code re
Hi Chris,
I uploaded new webrev:
http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.06/
It shows help messages as below:
```
$ jhsdb jstack --help
--locks To print java.util.concurrent locks.
--mixed To print both Java and native frames (mixed mod
Hi Dan,
This looks good to me as far as just discussed the atomic copy is
considered to be a separate issue.
Thanks,
Serguei
On 7/6/19 06:53, Daniel D. Daugherty wrote:
Greetings,
During the code review for the following fix:
JDK-8227117 normal interpreter table is not restored after
Sorry, I meant "jhsdb debugd", not "clhsdb debugd".
Chris
On 7/8/19 12:09 AM, Chris Plummer wrote:
Hi Yasumasa,
I just noticed one more thing:
65 System.out.println(" --connect <[id@]host> To
connect to a remote debug server (sadebugd).");
Earlier on I incorrectly said t
Hi Yasumasa,
I just noticed one more thing:
65 System.out.println(" --connect <[id@]host> To
connect to a remote debug server (sadebugd).");
Earlier on I incorrectly said that jstack and other tools had a
references to "sadebugd" in the help output. It is actually "jsadebu
20 matches
Mail list logo
