On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote:
>
> On 7/24/2013 2:09 PM, Daniel Fuchs wrote:
>> On 7/24/13 8:01 AM, Mandy Chung wrote:
>>> I am catching up on this thread
>>>
>>> The thread count counts Java threads that are not hidden. I believe
>>> all VM internal threads are hidden
On 7/24/2013 2:09 PM, Daniel Fuchs wrote:
On 7/24/13 8:01 AM, Mandy Chung wrote:
I am catching up on this thread
The thread count counts Java threads that are not hidden. I believe
all VM internal threads are hidden from external API. This test runs
in othervm mode and AFAICT the thread
Thanks everyone for taking the time to dig into this issue.
I've done more testing and it turns out that my initial analysis was
wrong. There are no threads magically appearing and disappearing (it
was all caused by the monitoring tools I used). It rather seems that
there is an issue with termi
On 7/24/13 8:01 AM, Mandy Chung wrote:
On 7/23/2013 5:54 PM, David Holmes wrote:
On 23/07/2013 7:53 PM, Daniel Fuchs wrote:
On 7/23/13 11:45 AM, David Holmes wrote:
On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote:
> The result is that the offender is j.u.l.LogManager$Cleaner
thread. I
> am
On 7/23/2013 5:54 PM, David Holmes wrote:
On 23/07/2013 7:53 PM, Daniel Fuchs wrote:
On 7/23/13 11:45 AM, David Holmes wrote:
On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote:
> The result is that the offender is j.u.l.LogManager$Cleaner
thread. I
> am attaching the profiler snapshot (can be
Changeset: 558fe98d1ac0
Author:emc
Date: 2013-07-23 20:42 -0400
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/558fe98d1ac0
8016880: 42 tests in annot102* fail with compile-time errors.
Summary: Fixes error in type equality when bounds of type variables have
annotations.
Rev
Changeset: 129751018061
Author:jjg
Date: 2013-07-23 16:06 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/129751018061
8021215: javac gives incorrect doclint warnings on normal package statements
Reviewed-by: darcy
! src/share/classes/com/sun/tools/doclint/Checker.java
Changeset: 72727c4b6dec
Author:ccheung
Date: 2013-07-19 14:54 -0700
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/72727c4b6dec
8020791: [TESTBUG] runtime/jsig/Test8017498.sh failed to compile native code
Summary: Added -DLINUX to the gcc command and improved the .sh scr
Changeset: 8156630c1ed3
Author:mduigou
Date: 2013-07-23 13:20 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8156630c1ed3
8019840: Spec updates for java.util.function
Reviewed-by: mduigou, chegar
Contributed-by: brian.go...@oracle.com
! src/share/classes/java/util/function/B
Changeset: e1d19f9fd5a9
Author:jlaskey
Date: 2013-07-16 17:40 -0300
URL: http://hg.openjdk.java.net/jdk8/tl/nashorn/rev/e1d19f9fd5a9
8017585: Exclude two failing tests from Nashorn CC run
Reviewed-by: jlaskey, sundar, attila
Contributed-by: konstantin.she...@oracle.com
+ exclude/ex
Changeset: 16511b7e3d35
Author:emc
Date: 2013-07-22 17:57 -0400
URL: http://hg.openjdk.java.net/hsx/hotspot-rt/hotspot/rev/16511b7e3d35
8019632: Method parameters are not copied in clone_with_new_data
Summary: Add code to copy method parameters data in clone_with_new_data
Reviewed-b
Changeset: 6f3b940fe9f8
Author:igerasim
Date: 2013-07-23 18:57 +0400
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6f3b940fe9f8
8016838: improvement of RedefineBigClass and RetransformBigClass tests
Reviewed-by: dcubed
! test/ProblemList.txt
! test/java/lang/instrument/RedefineBi
If it is not possible to prevent JVM to start/stop arbitrary system
threads, then the test may still fail even with the fix, but I should
say the fix improves the test.
Line 176:
// assuming no system thread is added
so here at line 177 is still a potential failure, even very little.
To kno
On 23.07.2013 18:50, Daniel D. Daugherty wrote:
Yes. Do you have a pointer to the committed patch file?
If so, I'll take care of getting the fix into JDK8-T&L.
Thanks a lot! I really appreciate it.
Here's the link:
http://cr.openjdk.java.net/~igerasim/2commit/8016838-jdk8-ReBigClass-improved.
Ivan,
Sorry for forgetting about this issue...
On 7/23/13 8:14 AM, Ivan Gerasimov wrote:
Hello Daniel!
Can we please move forward with this issue?
Yes. Do you have a pointer to the committed patch file?
If so, I'll take care of getting the fix into JDK8-T&L.
Dan
I've just checked how the
Hello Daniel!
Can we please move forward with this issue?
I've just checked how the tests run against the latest jdk build (which
is 99), and the leak is still there.
Thus the proposed change (including ProblemList modifications) is still
actual.
Here's a link to the latest webrev:
http://cr
David,
On 2013-07-23 12:31, David Holmes wrote:
Hi Dmitry,
Looks okay.
Minor nit:
! return (int)threadIdField.getJInt(addr);
The cast should not be need as getJInt returns int.
Aside: this looks like a major bug in BasicField to me:
public long getJLong(Address addr) ...
A jlong
Hi Dmitry,
Looks okay.
Minor nit:
! return (int)threadIdField.getJInt(addr);
The cast should not be need as getJInt returns int.
Aside: this looks like a major bug in BasicField to me:
public long getJLong(Address addr) ...
A jlong is 64-bits but a long may be 32-bits!
David
On 2
Dmitry,
Looks good to me!
Thanks,
Peter
> -Original Message-
> From: serviceability-dev-boun...@openjdk.java.net [mailto:serviceability-
> dev-boun...@openjdk.java.net] On Behalf Of Dmitry Samersoff
> Sent: Tuesday, July 23, 2013 11:39 AM
> To: serviceability-dev@openjdk.java.net
> Subje
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/23/2013 11:39 AM, David Holmes wrote:
> Sorry - I took a closer look at the full test rather than just
> that patch. We already have this code to try and help expose these
> intermittent failures:
>
> 213 // Nightly testing showed some
On 7/23/13 11:45 AM, David Holmes wrote:
On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote:
> The result is that the offender is j.u.l.LogManager$Cleaner thread. I
> am attaching the profiler snapshot (can be opened in eg. jvisualvm)
That doesn't quite make sense. The Cleaner thread is a shutdown
On 23/07/2013 7:53 PM, Daniel Fuchs wrote:
On 7/23/13 11:45 AM, David Holmes wrote:
On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote:
> The result is that the offender is j.u.l.LogManager$Cleaner thread. I
> am attaching the profiler snapshot (can be opened in eg. jvisualvm)
That doesn't quite
On 23/07/2013 7:24 PM, Jaroslav Bachorik wrote:
> The result is that the offender is j.u.l.LogManager$Cleaner thread. I
> am attaching the profiler snapshot (can be opened in eg. jvisualvm)
That doesn't quite make sense. The Cleaner thread is a shutdownhook, it
should not be starting unless the
On 7/23/13 11:35 AM, Jaroslav Bachorik wrote:
As I wrote in my reply to David the offending thread is
j.u.l.LogManager$Cleaner which kicks in randomly.
Argh... Logging again :-)
This would confirm my observations that the discrepancy is always at
most one thread more than expected.
What you
Hi Everybody,
Please, review the fix.
http://cr.openjdk.java.net/~dsamersoff/JDK-8019396.SA-JDI/webrev.01/
Method sun.jvm.hotspot.runtime.OSThread.initialize throws a
sun.jvm.hotspot.types.WrongTypeException with message: field
"_thread_id" in type OSThread is not of type jint, but instead of t
Sorry - I took a closer look at the full test rather than just that
patch. We already have this code to try and help expose these
intermittent failures:
213 // Nightly testing showed some intermittent failure.
214 // Check here to get diagnostic information if some strange
21
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/23/2013 10:25 AM, Daniel Fuchs wrote:
> Hi Jaroslav,
>
> This looks like a tough problem as it is altogether possible that
> some of the VM daemon threads will terminate during the duration of
> the call - and if that's the case, the condition:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue 23 Jul 2013 11:19:13 AM CEST, David Holmes wrote:
> On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote:
>> On 07/23/2013 10:19 AM, David Holmes wrote:
>>> Hi Jaroslav,
>>>
>>> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote:
The
java/lang/
On 23/07/2013 6:29 PM, Jaroslav Bachorik wrote:
On 07/23/2013 10:19 AM, David Holmes wrote:
Hi Jaroslav,
On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote:
The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test
seems to be failing intermittently.
The test checks the functionality o
On 23/07/2013 6:25 PM, Daniel Fuchs wrote:
Hi Jaroslav,
This looks like a tough problem as it is altogether possible that
some of the VM daemon threads will terminate during the duration
of the call - and if that's the case, the condition:
new peak >= old peak + delta
might not even be true.
On 07/23/2013 10:19 AM, David Holmes wrote:
> Hi Jaroslav,
>
> On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote:
>> The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test
>> seems to be failing intermittently.
>>
>> The test checks the functionality of the
>> j.l.m.ThreadMXBean.resetPe
Hi Jaroslav,
This looks like a tough problem as it is altogether possible that
some of the VM daemon threads will terminate during the duration
of the call - and if that's the case, the condition:
new peak >= old peak + delta
might not even be true.
I am not a VM specialist so I don't know whe
Hi Jaroslav,
On 22/07/2013 9:55 PM, Jaroslav Bachorik wrote:
The java/lang/management/ThreadMXBean/ResetPeakThreadCount.java test
seems to be failing intermittently.
The test checks the functionality of the
j.l.m.ThreadMXBean.resetPeakThreadCount() method. It does so by
capturing the current va
33 matches
Mail list logo
