Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-6324616

SA: Serviceability tools need to be multi-threaded


    • Type: Enhancement
    • Status: Closed
    • Priority: P3
    • Resolution: Won't Fix
    • Affects Version/s: 6
    • Fix Version/s: None
    • Component/s: hotspot
    • Labels:
    • Subcomponent:
    • CPU:
    • OS:


      I was running on a Niagara (8x4 SPARC) and tried to give a customer a demonstration of "jmap -histo". Admittedly the heap was 2GB, but took forever to iterate the heap. In fact, it took so long that after we had waited too long we started the application on a v20z (2x2 Opteron) and ran "jmap -histo" there and got essentially the same stack map in about 40 seconds (which is not unreasonable), then we killed the "jmap -histo" that hadn't yet come back on the Niagara.

      I'm pretty sure the problem is that "jmap -histo" (and the other tools?) is single-threaded. One doesn't notice that so much on a small box (Sun Blade 2500 or v20z) because the base processor is so fast. But a single thread on a Niagara is one quarter of a 1.6GHZ(?) part, or about a 400MHz processor. I guess an aggrevating factor is that one thinks of Niagara as a big box, so one runs big applications on it. I was "only" running a 2GB heap, but the machine had 32GB of physical memory and the customer was thinking of trying the 64-bit JVM. "jmap -histo" would not scale to those sizes.

      The solution is to make "jmap -histo" (and the other tools?) multi-threaded. It might be easy to use the block offset table (or equivalent) to chop the heap into regions and iterate them in multiple threads. Or maybe one could have some threads figuring out where the object boundaries were and other threads figuring out the sizes and types, using work-stealing to balance the loads. But I shouldn't design the solution for you. The right solution might be different for the different tools. But it will take some thought to figure out, and a lot of work to implement.

      I'm making this an RFE since it's not technically broken. But it is unusable.




            • Assignee:
              sballal Sharath Ballal (Inactive)
              pbk Peter Kessler
            • Votes:
              0 Vote for this issue
              2 Start watching this issue


              • Created: