Posts for the month of September 2011

ThreadList changes

Revision 588 has some significant ThreadList changes that are supposed to fix the problem of ThreadInfos being associated with wrong java.lang.Thread objects (the infamous "DiningPhil 8" problem). This happened if thread objects were sequentially created with the same reference value (due to collection of the previous object), and could have caused all sort of things from exceptions to missed paths. The culprit was the thread object to ThreadInfo map that was used by ThreadInfo.getThreadInfo(objRef), which was utterly unaware of re-used reference values.

Since this map needs to be state managed, we now use ThreadList for the mapping. ThreadInfos are added upon creation, and are removed when the object is collected. This has a number of implications for ThreadList:

  • the thread list can contain terminated threads
  • the list can shrink along a given path
  • thread ids don't have to correspond with storing order !!
  • thread ids can be re-used

Thread ids are re-used in order to be packed (which is required to efficiently keep track of referencing threads in ElementInfo reftids).

To implement all this, two housekeeping mechanisms were added:

(1) object ReleaseActions which are triggered when an object is collected. So far, we only support class based ReleaseActions, but those are quite useful to manage JPF object to host Java object relations

(2) JVM.addPostGcAction(Runnable), which can be used to walk over all live heap objects after the sweep is finished.

All this should be transparent if you didn't store ThreadInfos in listeners or peers, relying on that they never change identity for the same thread object. However, ThreadInfo.getIndex() was renamed to getId(), and ElementInfo.getIndex() was renamed to getObjectRef(), to make clear there is no guarantee that respective values are used as index values in corresponding containers.