2

I am trying to ascertain the best possible approach of figuring out the impact of threads in wait state on a java process (more specifically memory and not cpu). Any suggestions that would help me figure out their impact (possibly via jvisualvm/jconsole etc) will be greatly appreciated.

Update: Current thread count is a few hundred in wait state - approx 500. I am trying to figure out the best way of checking whether it can/will have any potential impact on GC in old generation.

ali haider
  • 19,175
  • 17
  • 80
  • 149
  • what do you mean by "impact"? they don't do anything, they are just waiting...? – jtahlborn Oct 22 '13 at 15:31
  • possible duplicate of [How much memory does my java thread take?](http://stackoverflow.com/questions/4619211/how-much-memory-does-my-java-thread-take) – Jeff Storey Oct 22 '13 at 15:32
  • Maybe, if it's waiting for a while, some of its stack/data/code may get paged out, same as any user swappable allocations in processes. Why do you ask, anything specific? – Martin James Oct 22 '13 at 15:37

2 Answers2

3

The memory usage for a thread can be conceptually divided into:

  • The threads stack (defaults to 2MB I believe, but can be changed using the -Xss VM option and/or specified in the Thread constructor)

  • The java thread object and associated objects (located in the VM heap). Practically constant for a given implementation. Only be a few KB.

  • Native overhead - the kernel memory required to manage the thread. Should be neglible (a few KB).

  • User data managed by the thread (data reachable through its thread object or local variables). Can vary greatly.

The first three elements are easy to measure (they are practically constant with a VM instance, scaling linearly with number of threads), the last thing depends completely on the threads code/data.

Since the stack size usually grealy dominates the per thread cost (compared to the kernel overhead and thread object), the memory impact for a waiting thread can be simplified to its stack size.

For virtual mememory systems thats only the virtual impact (address space allocated), but not neccessarily the amount of physical memory assigned (unused stack space will never be assigned physical memory pages). 32-Bit systems can run out of address space very quickly when you create many threads (example: 1000 threads times 2MB stack size = 2GB).

Durandal
  • 19,919
  • 4
  • 36
  • 70
  • thanks for responding - thread count in wait state is aprox 500+ and I'm trying to figure out whether this could potentially impact GC in old generation. – ali haider Oct 22 '13 at 16:19
2

I am trying to ascertain the best possible approach of figuring out the impact of threads in wait state on a java process (more specifically memory and not cpu)

The affect of a single thread is going to be extremely minimal. Each thread gets allocated a certain amount of stack-space memory that is allocated outside of the heap. I believe typically this is 512k or 1M for 64-bit machines. This can be customized with the -XX:ThreadStackSize=YYY JVM argument where YYY is the size of the stack in kilobytes.

There also is the Thread object itself on the heap as well as the various accounting data kept by the JVM. Certainly any objects that the thread owns also need to be taken into account.

The only time you worry about this space is if you plan on having 1000s of threads or have very limited memory constraints.

Gray
  • 115,027
  • 24
  • 293
  • 354
  • thanks for responding - thread count in wait state is aprox 500+ and I'm trying to figure out whether this could potentially impact GC in old generation. – ali haider Oct 22 '13 at 16:20
  • Thread memory is outside of GC and will not affect it at all @alihaider. – Gray Oct 22 '13 at 16:51
  • Thanks - what I meant is if the thread is holding onto a (strong) reference and whether that object can be GC'd or not when its in the old generation (unless I'm having a brain freeze - it will not but I could be wrong). – ali haider Oct 22 '13 at 17:00
  • Oh I see. If the thread is long running then this may be the case. But if it needs the object there's not much you can do about it. Aggressively setting objects to `null` and calling `collection.clear()` inside of these paused threads may help @alihaider. – Gray Oct 22 '13 at 17:03