Hi,
With the perm gen removal changes the number of memory pools exported by
the VM has changed. This causes the tests
java/lang/management/MemoryMXBean/MemoryTest.java and
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
My suggested fix is to modify the tests to wor
Mikael,
the change looks good.
Thanks
/R
On Sep 5, 2012, at 10:13 AM, Mikael Gerdin wrote:
> Hi,
>
> With the perm gen removal changes the number of memory pools exported by the
> VM has changed. This causes the tests
> java/lang/management/MemoryMXBean/MemoryTest.java and
> java/lang/manag
On 05/09/2012 09:13, Mikael Gerdin wrote:
Hi,
With the perm gen removal changes the number of memory pools exported
by the VM has changed. This causes the tests
java/lang/management/MemoryMXBean/MemoryTest.java and
java/lang/management/MemoryMXBean/CollectionUsageThreshold.java to fail.
My
Hi David,
We could allocate some tens of kb... more if there are several thousand
threads with very long names... It's not a commonly called method, but
that's why the deadlock hasn't been exposed before. Yes you'd need to
be very near that existing cliff-edge...
Just thinking that yes i
Thanks!
Just to add: this is only relevant to internal VM threads, so the
numbers really should be quite small... (there won't be thousands of
theads examined, unless we're getting excessive with e.g. GC workers...).
On 05/09/12 10:16, Kevin Walls wrote:
Hi David,
We could allocate some tens of
On 5/09/2012 7:16 PM, Kevin Walls wrote:
Hi David,
We could allocate some tens of kb... more if there are several thousand
threads with very long names... It's not a commonly called method, but
that's why the deadlock hasn't been exposed before. Yes you'd need to be
very near that existing clif
Ah yes, so doing all the cleaning up in the destructor has to be the way
to do it:
Thanks
Kevin
// Called without Threads_lock, we can allocate String objects.
void ThreadTimesClosure::do_unlocked() {
EXCEPTION_MARK;
for (int i=0; i<_count; i++) {
Handle s = java_lang_String::create_
Alan,
On 2012-09-05 11:00, Alan Bateman wrote:
On 05/09/2012 09:13, Mikael Gerdin wrote:
Hi,
With the perm gen removal changes the number of memory pools exported
by the VM has changed. This causes the tests
java/lang/management/MemoryMXBean/MemoryTest.java and
java/lang/management/MemoryMXBea
Please review the patch below to make the jstatd tests a little bit more
resilient to different outputs of the jps command.
The jps command can output a couple of different error messages when
information is missing about the target process. See the errorString variable
in
http://hg.openjdk.j
On 05/09/2012 12:46, Mikael Gerdin wrote:
Good point about looking up where the java/lang/management tests for
hotspot-gc actually come from. It appears that we pick up the sources
from the latest promoted build of jdk8 for those tests. So there's
really no point in pushing the fix to hotspot
On 05/09/2012 12:51, Staffan Larsen wrote:
:
diff --git a/test/sun/tools/jstatd/jpsOutput1.awk
b/test/sun/tools/jstatd/jpsOutput1.awk
--- a/test/sun/tools/jstatd/jpsOutput1.awk
+++ b/test/sun/tools/jstatd/jpsOutput1.awk
@@ -7,7 +7,7 @@
matched++;
}
-/^[0-9]+ -- process information unavailab
Looks good.
/R
On Sep 5, 2012, at 1:51 PM, Staffan Larsen wrote:
> Please review the patch below to make the jstatd tests a little bit more
> resilient to different outputs of the jps command.
>
> The jps command can output a couple of different error messages when
> information is missing a
Looks good for me.
-Dmitry
On 2012-09-05 15:51, Staffan Larsen wrote:
> Please review the patch below to make the jstatd tests a little bit more
> resilient to different outputs of the jps command.
>
> The jps command can output a couple of different error messages when
> information is missing
Changeset: 5ca450af2a9e
Author:sla
Date: 2012-09-05 14:42 +0200
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/5ca450af2a9e
6963102: Testcase failures sun/tools/jstatd/jstatdExternalRegistry.sh and
sun/tools/jstatd/jstatdDefaults.sh
Summary: Make tests more resilient by allowing f
Hi again,
I found a memory leak while testing this. thread->name() uses the
ResourceArea. I don't think we've been able to call this enough in the
past to notice the leak, but now we can... Adding a ResourceMark
(management.cpp line 1859) there's no leak.
I updated the webrev in the same
It looks good.
As far as I understand allocating memory in ResourceArena (with Amalloc)
should not cause GC.
Thanks,
Serguei
On 9/5/12 9:26 AM, Kevin Walls wrote:
Hi again,
I found a memory leak while testing this. thread->name() uses the
ResourceArea. I don't think we've been able to cal
Changeset: e129833555f6
Author:valeriep
Date: 2012-09-04 18:41 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/e129833555f6
7044060: Need to support NSA Suite B Cryptography algorithms
Summary: Add support for DSA parameter generation and OIDs for NSA Suite B
algorithms.
Revi
Changeset: 6b2a363213f4
Author:katleman
Date: 2012-08-30 10:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/corba/rev/6b2a363213f4
Added tag jdk8-b54 for changeset 16c82fc74695
! .hgtags
Changeset: e8a0e84383d6
Author:lana
Date: 2012-08-30 20:10 -0700
URL: http://h
Changeset: 109c9e1f2d85
Author:katleman
Date: 2012-08-30 10:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxws/rev/109c9e1f2d85
Added tag jdk8-b54 for changeset 91970935926a
! .hgtags
Changeset: 3b77f0c58018
Author:katleman
Date: 2012-08-30 10:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/hotspot/rev/3b77f0c58018
Added tag jdk8-b54 for changeset e8fb566b9466
! .hgtags
Changeset: 0cb5f2471628
Author:katleman
Date: 2012-08-30 10:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/0cb5f2471628
Added tag jdk8-b54 for changeset 7dd81ccb7c11
! .hgtags
Changeset: 7c2363666890
Author:lana
Date: 2012-08-30 20:10 -0700
URL: http://hg
Changeset: c47742f53f99
Author:katleman
Date: 2012-08-30 10:27 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/c47742f53f99
Added tag jdk8-b54 for changeset 9cf72631baf5
! .hgtags
Changeset: e48e7e1f026b
Author:lana
Date: 2012-08-30 20:14 -0700
URL: http
Looks ok.
Minor style nit: please add spaces around operators eg i=0, i<_count
Thanks,
David
On 6/09/2012 2:26 AM, Kevin Walls wrote:
Hi again,
I found a memory leak while testing this. thread->name() uses the
ResourceArea. I don't think we've been able to call this enough in the
past to noti
Somehow serviceability-dev was dropped from the CC list.
I uploaded a new webrev since I thought Bengt had a point about being
consistent.
We talked about where to integrate the fix during the perm gen removal
meeting and decided that we'd like to push this through jdk8/tl/jdk
since we're not in
25 matches
Mail list logo
