[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-hotspot-runtime-dev
Subject:    HOARD
From:       Dave.Dice () Sun ! COM (Dave Dice)
Date:       2007-12-20 18:51:16
Message-ID: 0JTD0008W2YCJK40 () mail-amer ! sun ! com
[Download RAW message or body]

Hi Ramki,

Hoard is perfectly good allocator, and as you noted, you can use LD_PRELOAD to
enable it.  (IIRC, hoard.org provides SPARC .so-es for download, so it's nearly
painless to try).   At various times I've tried it with hotspot and it behaved
well.  The latest version uses per-thread subheaps, so there's no
synchronization (contended or uncontended) for "normal" allocation and
deallocation.  Normal being defined as the case where the same thread that
allocates a block also frees the block.  If on Solaris, however, I'd recommend
libumem in slight preference over hoard.  Libumem is fully supported and tuned
specifically for solaris.   Libumem and hoard share many concepts, the key being
the use of subheaps to diffuse contention and to avoid false sharing.  They both
suffer from increased footprint, however, at least as compared to the default
allocators.  The Lea allocator (the default on linux) and the solaris libc
allocator (based on Tarjan trees augmented with segregated free lists for common
small sizes) use a common heap and a global local.  They both have excellent
footprint and heap density.  

Beyond footprint, the only problem I've ever run into with hoard or libumem was
a red-black tree where various threads were adding and removing nodes on MP
systems.  Over time the traversal from the root to the leaves ended up touching
nodes allocated by different threads, and thus in different subheaps, and thus
covered by different (small page) TLBs.  (You get the picture (:>)).  

Regards
Dave


p.s., really old JVMs use the __malloc_lock around thread suspension to avoid
deadlock, in which case you can't substitute allocators. 



| -----Original Message-----
| From: hotspot-runtime-dev-bounces at openjdk.java.net 
| [mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On 
| Behalf Of Y Srinivas Ramakrishna
| Sent: Thursday, December 20, 2007 1:14 PM
| To: Keith Holdaway
| Cc: hotspot-gc-dev at openjdk.java.net; 
| hotspot-runtime-dev at openjdk.java.net
| Subject: Re: HOARD
| 
| 
| 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 ...
| > 
| > 
| 



[prev in list] [next in list] [prev in thread] [next in thread]