-
Enhancement
-
Resolution: Fixed
-
P4
-
1.3.0, 5.0
-
hopper
-
generic, sparc
-
generic, solaris_2.6
/* Infrastructure for using C-heap allocators that use not a single lock
* (as in libc's __mallock_lock above), but possibly several (or perhaps
* none). The malloc_raisBarrier() and malloc_lowerBarrier() are synchronous
* calls that implement the necessary actions required to "fence off"
* malloc resources, and must be supplied by the allocator. They may
* be no-ops if there are no critical sections inside the allocator
* (or if threads can not be suspended in critical sections).
If it exists with hotspot pl. document and not require ISVs to use libc malloc only.
4451800 is identical to 4432860, which already on the MDETop10 list.
4432860 is filed against java 1.2.2_07 and 4451800 is filed against
Hotspot. The issue is that the Solaris memory allocators are not
optimal for multithreaded apps since libc locks up the entire heap for
an allocation. Allocators like SmartHeap(libHoard) break up the heap
and into object pools of different sizes(size can be customized) and
allocate memory from them. Performance improvements in scalability, and
hardware requirements result from using third party allocators. In the
immediate case, iPlanet Application Server needs this feature, so that
they can plugin the allocator they want.
chris.atwood@Corp 2001-05-14
* (as in libc's __mallock_lock above), but possibly several (or perhaps
* none). The malloc_raisBarrier() and malloc_lowerBarrier() are synchronous
* calls that implement the necessary actions required to "fence off"
* malloc resources, and must be supplied by the allocator. They may
* be no-ops if there are no critical sections inside the allocator
* (or if threads can not be suspended in critical sections).
If it exists with hotspot pl. document and not require ISVs to use libc malloc only.
4451800 is identical to 4432860, which already on the MDETop10 list.
4432860 is filed against java 1.2.2_07 and 4451800 is filed against
Hotspot. The issue is that the Solaris memory allocators are not
optimal for multithreaded apps since libc locks up the entire heap for
an allocation. Allocators like SmartHeap(libHoard) break up the heap
and into object pools of different sizes(size can be customized) and
allocate memory from them. Performance improvements in scalability, and
hardware requirements result from using third party allocators. In the
immediate case, iPlanet Application Server needs this feature, so that
they can plugin the allocator they want.
chris.atwood@Corp 2001-05-14
- relates to
-
JDK-4873131 JVM hangs up with C++ std lib because of mutex deadlock in 1.3.1_03/1.4.0_0X
- Closed