HOARD
Y Srinivas Ramakrishna
Y.S.Ramakrishna at Sun.COM
Thu Dec 20 18:14:18 UTC 2007
Hi Keith --
> I researched HOARD:
>
> http://developers.sun.com/solaris/articles/multiproc/multiproc.html
>
> The Hoard memory allocator is a fast, scalable, and memory-efficient
> memory allocator. It runs on a variety of platforms, including Linux,
> Solaris, and Windows. Hoard is a drop-in replacement for malloc() that
> can dramatically improve application performance, especially for
> multithreaded programs running on multiprocessors.
>
> Is this purely an OS change; or does one have to make changes to the
> VM source to use HOARD instead of malloc etc?
Have you found that malloc() becomes a bottleneck in your application?
The JVM's use of the C-heap should usually not be more than a minor
blip on the performance profile, as such i would not think that Hoard's
scalability and performance would contribute much to the bottom line
of JVM performance, at least wrt pure Java applications.
On the other hand, if your application has a lot of native (JNI) code that
relies on the use of the C-heap (especially in a multi-threaded way)
then it's likely that your application will benefit from the use of Hoard.
As pointed out by the authors in the article, it should suffice (at least
on Solaris) to have your environment with LD_PRELOAD defined to include
the location of libhoard.so. My guess would be that the VM would then
use libhoard.so's malloc in preference to libc.so's malloc.
However, i have never personally tried this myself. I think members of the
runtime team have, in the past, experimented with alternate
malloc implementations, perhaps including Hoard. I am cross-posting
to their mailing list and hopefully they will be able to provide more
useful advice & help on this.
-- ramki
>
> keith
>
>
> Keith R Holdaway
> Java Development Technologies<
>
> SAS... The Power to Know
>
> Carpe Diem ...
>
>
More information about the hotspot-gc-dev
mailing list