Question

I’m developing tool, which takes Java code and generate code for getting estimations for execution time of basic blocks, loops and methods. After some block is executed, we put it’s time to our tool. The program model is stored in next representation

static Hashtable<String, Hashtable<Integer, Hashtable<String, pair>>> method2Data = new Hashtable<String, Hashtable<Integer, Hashtable<String, pair>>>();

static Hashtable<String, Vector<String>> class2Method = new Hashtable<String, Vector<String>>();

And a time putted by a method

 public static void addBlock(int id, double time, String meth, String thread);

But I have next problem. On each call of addBlock, we take something from method2data. Since we could have a code like

for (int i = 0; i < n; i++)
  for (int j = 0; j < n; j++)
    for (int k = 0; k < n; k++) {
      addBlock(0,...);
      addBlock(m,...);
    }

we call addBlock a lot of time.
Unfortunately, after some constant time of working on our claster, program just stop working. It still looks like process, but doesn’t take any cpu. I found, that if I remove code, which take something from method2data, then all is ok. So, I guess, that there is some problem with accesses to Hashtable. Have anybody good ideas?

Thanks to all, it seems, that I have a deadlock in case of concurrent accesses and perhaps could run out of memory when there is no concurrent things.

Answer 1

If you are using Java5 or above, you shouldn’t use Hashtable, but ConcurrentHashMap, which provides much better scalability via lock striping, thus might solve the problem instantly (in case you have a deadlock or starvation issue, which is a possibility based on your – incomplete – description). And on the same line, don’t use Vector, but some List implementation instead. Both Hashtable and Vector are old collection implementations which are synchronized, in this Vector’s case possibly unnecessarily.

[Update] As @finnw rightly pointed out, even if the ConcurrentHashMap seems to help, you can’t be sure that the root cause is really solved. Thorough analysis and testing is required to see whether or not your code is actually thread safe. Without seeing the code in addBlock(), we can’t conclude on this. [/Update]

Also, as others noted, keeping the profile data in memory is not a good idea for large programs, as this may influence the performance characteristics you are trying to measure, and you may even run out of memory.