When a customer used JVMTI in jdk5, memory leaks. 
Specifically speaking, when a callback function is set for the event
of JVMTI_EVENT_THREAD_START, this leak occurs.

The following source code portions are based on jdk5.0u16.

When a call back function is set for the event of JVMTI_EVENT_THREAD_START,
every time Java application creates threads, JvmtiThreadState is created in JVM.
At the line# 49( constructor of JvmtiThreadState and GrowableArray),
the second argument is set to true.

----
  [hotspot/src/share/vm/prims/jvmtiThreadState.cpp]
   30 JvmtiThreadState::JvmtiThreadState(JavaThread* thread)
    ...
   47   // add all the JvmtiEnvThreadState to the new JvmtiThreadState
   48   int ec = JvmtiEnvBase::env_count();
   49   _env_thread_states    = new (ResourceObj::C_HEAP) GrowableArray<JvmtiEnvThreadState *>(ec+1,true);
    ...
   66 }
-----

When the second argument is true, the field "_data" in GrowableArray is allocated to c heap.
Because there is no destructor for GrowableArray, to call clear_and_deallocate() and
release _data are needed before the release of GrowableArray.

  [hotspot/src/share/vm/utilities/growableArray.cpp]
   31 GenericGrowableArray::GenericGrowableArray(int initial_size, int initial_len, GrET* filler, bool c_heap) {
   32   _len = initial_len;
   33   _max = initial_size;
   34   assert(_len >= 0 && _len <= _max, "initial_len too big");
   35   _arena = (c_heap ? (Arena*)1 : NULL);
   36   if (on_C_heap()) {
   37     _data = NEW_C_HEAP_ARRAY(GrET*, _max);
   38   } else {
   39     _data = NEW_RESOURCE_ARRAY(GrET*, _max);
   40   }
   41   for (int i = 0; i < _len; i++) _data[i] = filler;
   42 #ifdef ASSERT
   43   if (!on_C_heap()) {
   44     _nesting = Thread::current()->resource_area()->nesting();
   45   }
   46 #endif
   47 }
    ...
  222 void GenericGrowableArray::clear_and_deallocate() {
  223   assert(on_C_heap(),
  224          "clear_and_deallocate should only be called when on C heap");
  225   clear();
  226   if (_data != NULL) {
  227     FreeHeap(_data);
  228     _data = NULL;
  229   }
  230 }

However, there is no call for clear_and_deallocate() before _env_thread_states is discarded
in destructor, ~JvmtiThreadState().

  [hotspot/src/share/vm/prims/jvmtiThreadState.cpp]
   69 JvmtiThreadState::~JvmtiThreadState()   {
    ...
   79   int ec = env_count();
   80   assert(ec == JvmtiEnvBase::env_count(), "Should be one JvmtiEnvThreadState per environment");
   81   for (int i = 0; i < ec ; ++i) {
   82     JvmtiEnvThreadState *ets = _env_thread_states->at(i);
   83     _env_thread_states->at_put(i, NULL);
   84     delete ets;
   85   }
   86   FreeHeap(_env_thread_states);
   87   _env_thread_states = NULL;

So, every time JvmtiThreadState is created, which is, application creates threads, memory will leak.