Hi,
thanks for fixing. What about a backport to 11?
Thanks
-Sven
Mandy Chung schrieb am Mo., 15. Okt. 2018, 19:50:
> Hi Sven,
>
> It's indeed a bug in the order of names and values when constructing
> CompositeData for StackTraceElement. I created
> https://bugs.openjdk.java.net/browse/JDK
Hi Alex, Chris and JC,
Please review an updated version of the patch that addresses these issues.
Webrev: http://cr.openjdk.java.net/~dtitov/8211736/webrev.03/
Issue: https://bugs.openjdk.java.net/browse/JDK-8211736
Thanks!
--Daniil
On 10/12/18, 9:52 AM, "Alex Menkov" wrote:
Hi Daniil,
Hi Dean,
Thanks for tackling this.
I'm still struggling to fully grasp why we need both the PerfCounters
and the regular counters. I get that we have to decrement the live
counts before ensure_join() has allowed Thread.join() to return, to
ensure that if we then check the number of threads it
New webrev:
http://cr.openjdk.java.net/~dlong/8021335/webrev.4/
dl
On 10/16/18 11:59 AM, dean.l...@oracle.com wrote:
On 10/16/18 10:28 AM, JC Beyler wrote:
Hi Dean,
I noticed a typo here :
"are atomically" is in the comment but should no longer be there I
believe; the sentence probably shou
Hi Dmitry,
On 16/10/2018 10:46 PM, Dmitry Samersoff wrote:
David,
The fix looks good to me.
Thanks for taking a look.
PS: This code has lots of formatting nits like missed spaces.
It's clearly out of scope of this fix, but it might be worth to
launch a second webrev.
out of scop
On 10/16/18 10:28 AM, JC Beyler wrote:
Hi Dean,
I noticed a typo here :
"are atomically" is in the comment but should no longer be there I
believe; the sentence probably should be:
// These 2 counters are like the above thread counts, but are
Fixed!
Any way we could move this test into a h
https://bugs.openjdk.java.net/browse/JDK-8021335
http://cr.openjdk.java.net/~dlong/8021335/webrev.3/
This change attempts to fix an old and intermittent problem with
ThreadMXBean thread counts.
Changes have 3 main parts:
1. Make sure hidden threads don't affect counts (even when exiting)
2. Fix
David,
The fix looks good to me.
PS: This code has lots of formatting nits like missed spaces.
It's clearly out of scope of this fix, but it might be worth to
launch a second webrev.
-Dmitry
On 15.10.2018 8:12, David Holmes wrote:
> Bug: https://bugs.openjdk.java.net/browse/JDK-8211909
Still seeing a 1/1000 kill002 failure on solais-sparcv9-debug.
The message waiting for "killing" is working correctly
and only one compound prompt is being delivered.
After all the killing a final cont is issued to proceed to the last
breakpoint.
The simple prompt is seen in the pending reply
On 15/10/2018 23:02, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/
This simple patch fixes the issue Sven reports [1] where
the order of names and values when creating CompositeData
for StackTraceElement is mismatched. I keep names/values
in th
Hi Mandy,
This looks good to me.
best regards,
-- daniel
On 15/10/2018 23:02, Mandy Chung wrote:
Webrev:
http://cr.openjdk.java.net/~mchung/jdk12/webrevs/8212197/webrev.00/
This simple patch fixes the issue Sven reports [1] where
the order of names and values when creating CompositeData
for
11 matches
Mail list logo