-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
6
Below is my original main about the problem.
Coleen and I observed TIMEOUTs in Nightly testing on Solaris AMD64:
nsk/serial/Unsafe/allocateMemory/allocmem001
nsk/serial/Unsafe/allocateMemory/reallocmem001
I am running full runThis on my SB2500.
And it sits in the ThreadGC test for 5 hours already.
I attached dbx and it shows that gc is in the
MutableSpace::mangle_unused_area() method almost all time:
Attached to process 2983 with 16 LWPs
t@1 (l@1) stopped in ___lwp_cond_wait at 0xff31f9c8
0xff31f9c8: ___lwp_cond_wait+0x0004: ta 8
Current function is Monitor::wait (optimized)
211 wait_status = _Lock_Event->wait();
[t@1 l@1]: threads
> t@1 a l@1 ?() running in ___lwp_cond_wait()
t@2 b l@2 _start() running in ___lwp_cond_wait()
t@3 b l@3 _start() running in ___lwp_cond_wait()
t@4 b l@4 _start() running in mangle_unused_area()
t@5 b l@5 _start() running in ___lwp_cond_wait()
t@6 b l@6 _start() running in ___lwp_cond_wait()
t@7 b l@7 _start() sleep on 0xfee68f00 in __lwp_park()
t@8 b l@8 _start() running in ___lwp_cond_wait()
t@9 b l@9 _start() running in ___lwp_cond_wait()
t@10 b l@10 _start() running in ___lwp_cond_wait()
t@11 b l@11 _start() running in ___lwp_mutex_lock()
t@12 b l@12 _start() running in ___lwp_cond_wait()
t@13 b l@13 _start() running in ___lwp_cond_wait()
t@14 b l@14 _start() running in ___lwp_cond_wait()
t@57527 b l@57527 _start() running in ___lwp_mutex_lock()
t@57528 b l@57528 _start() running in ___lwp_mutex_lock()
[t@1 l@1]: thread t@4
t@4 (l@4) stopped in MutableSpace::mangle_unused_area (optimized) at line 139 in
file "/export/home2/work/6297035/src/cpu/sparc/vm/copy_sparc.hpp"
139 *to++ = value;
[t@4 l@4]: where
current thread: t@4
=>[1] MutableSpace::mangle_unused_area(this = ???) (optimized), at 0xfdf899f0 (line ~139) in "/export/home2/work/6297035/src/cpu/sparc/vm/copy_sparc.hpp"
[2] PSScavenge::invoke_no_policy(notify_ref_lock = ???) (optimized), at 0xfe09c868 (line ~317) in "/export/home2/work/6297035/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp"
[3] PSMarkSweep::invoke(notify_ref_lock = ???, maximum_heap_compaction = ???)(optimized), at 0xfe08bc50 (line ~48) in "/export/home2/work/6297035/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp"
[4] VM_ParallelGCSystemGC::doit(this = ???) (optimized), at 0xfe2d4f84 (line ~278) in "/export/home2/work/6297035/src/share/vm/gc_implementation/shared/vmGCOperations.cpp"
[5] VM_Operation::evaluate(this = ???) (optimized), at 0xfe2f8694 (line ~25) in "/export/home2/work/6297035/src/share/vm/runtime/vm_operations.cpp"
[6] VMThread::loop(this = ???) (optimized), at 0xfe2f7518 (line ~271) in "/export/home2/work/6297035/src/share/vm/runtime/vmThread.cpp"
[7] VMThread::run(this = ???) (optimized), at 0xfe2f67f4 (line ~195) in "/export/home2/work/6297035/src/share/vm/runtime/vmThread.cpp"
[8] _start(0x13b300, 0x2, 0xfee465ec, 0x21800, 0xfedb8ad4, 0x13bc90), at 0xfdfe6eec
[t@4 l@4]: x 0xfdf899f0/3i
0xfdf899f0: mangle_unused_area+0x0098: st %l5, [%l6]
0xfdf899f4: mangle_unused_area+0x009c: inc 4, %l4
0xfdf899f8: mangle_unused_area+0x00a0: inc -1, %l3
[t@4 l@4]: print $l3
$l3 = 15253648U
[t@4 l@4]:
Coleen and I observed TIMEOUTs in Nightly testing on Solaris AMD64:
nsk/serial/Unsafe/allocateMemory/allocmem001
nsk/serial/Unsafe/allocateMemory/reallocmem001
I am running full runThis on my SB2500.
And it sits in the ThreadGC test for 5 hours already.
I attached dbx and it shows that gc is in the
MutableSpace::mangle_unused_area() method almost all time:
Attached to process 2983 with 16 LWPs
t@1 (l@1) stopped in ___lwp_cond_wait at 0xff31f9c8
0xff31f9c8: ___lwp_cond_wait+0x0004: ta 8
Current function is Monitor::wait (optimized)
211 wait_status = _Lock_Event->wait();
[t@1 l@1]: threads
> t@1 a l@1 ?() running in ___lwp_cond_wait()
t@2 b l@2 _start() running in ___lwp_cond_wait()
t@3 b l@3 _start() running in ___lwp_cond_wait()
t@4 b l@4 _start() running in mangle_unused_area()
t@5 b l@5 _start() running in ___lwp_cond_wait()
t@6 b l@6 _start() running in ___lwp_cond_wait()
t@7 b l@7 _start() sleep on 0xfee68f00 in __lwp_park()
t@8 b l@8 _start() running in ___lwp_cond_wait()
t@9 b l@9 _start() running in ___lwp_cond_wait()
t@10 b l@10 _start() running in ___lwp_cond_wait()
t@11 b l@11 _start() running in ___lwp_mutex_lock()
t@12 b l@12 _start() running in ___lwp_cond_wait()
t@13 b l@13 _start() running in ___lwp_cond_wait()
t@14 b l@14 _start() running in ___lwp_cond_wait()
t@57527 b l@57527 _start() running in ___lwp_mutex_lock()
t@57528 b l@57528 _start() running in ___lwp_mutex_lock()
[t@1 l@1]: thread t@4
t@4 (l@4) stopped in MutableSpace::mangle_unused_area (optimized) at line 139 in
file "/export/home2/work/6297035/src/cpu/sparc/vm/copy_sparc.hpp"
139 *to++ = value;
[t@4 l@4]: where
current thread: t@4
=>[1] MutableSpace::mangle_unused_area(this = ???) (optimized), at 0xfdf899f0 (line ~139) in "/export/home2/work/6297035/src/cpu/sparc/vm/copy_sparc.hpp"
[2] PSScavenge::invoke_no_policy(notify_ref_lock = ???) (optimized), at 0xfe09c868 (line ~317) in "/export/home2/work/6297035/src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp"
[3] PSMarkSweep::invoke(notify_ref_lock = ???, maximum_heap_compaction = ???)(optimized), at 0xfe08bc50 (line ~48) in "/export/home2/work/6297035/src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp"
[4] VM_ParallelGCSystemGC::doit(this = ???) (optimized), at 0xfe2d4f84 (line ~278) in "/export/home2/work/6297035/src/share/vm/gc_implementation/shared/vmGCOperations.cpp"
[5] VM_Operation::evaluate(this = ???) (optimized), at 0xfe2f8694 (line ~25) in "/export/home2/work/6297035/src/share/vm/runtime/vm_operations.cpp"
[6] VMThread::loop(this = ???) (optimized), at 0xfe2f7518 (line ~271) in "/export/home2/work/6297035/src/share/vm/runtime/vmThread.cpp"
[7] VMThread::run(this = ???) (optimized), at 0xfe2f67f4 (line ~195) in "/export/home2/work/6297035/src/share/vm/runtime/vmThread.cpp"
[8] _start(0x13b300, 0x2, 0xfee465ec, 0x21800, 0xfedb8ad4, 0x13bc90), at 0xfdfe6eec
[t@4 l@4]: x 0xfdf899f0/3i
0xfdf899f0: mangle_unused_area+0x0098: st %l5, [%l6]
0xfdf899f4: mangle_unused_area+0x009c: inc 4, %l4
0xfdf899f8: mangle_unused_area+0x00a0: inc -1, %l3
[t@4 l@4]: print $l3
$l3 = 15253648U
[t@4 l@4]:
- relates to
-
JDK-6344442 Large page size causes slowdown of java -version in fastdebug -server mode on solamd64
- Closed