GC Problems...

Wed Sep 8 13:28:00 GMT 2004

Hi All,
>>The problem exists in both the COM environment we're running under, and the 
>>simple test case application I'm attaching here, there appears to be a memory 
>>leak.
>>>There is a known leak with thread creation on win32. I'm not sure if it 
>applies to JvAttachCurrentThread(), but its possible. See 
>http://gcc.gnu.org/PR14751
>>I heard Mohan was testing a fix for this, but I'm not sure what the 
>status is now. I suggest attaching the thread just once instead of 
>continuously attaching and detaching it.

I don't pretend to know the entire history of this, but from what I can
interpret from this post, JvAttachCurrentThread is supposed to avoid the
leakage of the 24 bytes from what I read here:
- http://gcc.gnu.org/ml/java/2002-03/msg00082.html
- http://gcc.gnu.org/ml/java/2002-03/msg00144.html
As for this:
http://gcc.gnu.org/PR14751
...I initially I thought I had a good handle (no pun intended) on the
problem, but walked away because it needed further investigation and
I got distracted by other things. Note that the issue in the PR relates
to leakage of OS handles, not memory (although the two issues probably
go hand in hand).
I took another swing at PR14751 last night and this is what I came
up with. It seems to fix both PR14751 as well as Simon's GCTest troubles.
I'll submit an official patch after I build and test the world. I'll
probably do this with a cvs -D 2004年09月01日 because I'm kind of scared
to get and build HEAD, unless someone has recently successfully gotten
and built it. I feel comfortable doing this because the non-Win32 portion
of this patch could probably be committed as obvious....
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/
Index: win32-threads.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/win32-threads.cc,v
retrieving revision 1.11
diff -u -2 -r1.11 win32-threads.cc

--- win32-threads.cc	31 Oct 2003 03:36:38 -0000	1.11
+++ win32-threads.cc	8 Sep 2004 13:13:05 -0000
@@ -263,4 +263,5 @@
 _Jv_Thread_t *data = (_Jv_Thread_t*)_Jv_Malloc(sizeof(_Jv_Thread_t));
 data->flags = 0;
+ data->handle = 0;
 data->thread_obj = obj;
 data->interrupt_event = 0;
@@ -276,4 +277,5 @@
 if (data->interrupt_event)
 CloseHandle(data->interrupt_event);
+ CloseHandle(data->handle);
 _Jv_Free(data);
 }
@@ -366,5 +368,4 @@
 data->flags |= FLAG_START;
 
- // FIXME: handle marking the info object for GC.
 info = (struct starter *) _Jv_AllocBytes (sizeof (struct starter));
 info->method = meth;
@@ -380,5 +381,5 @@
 data->flags |= FLAG_DAEMON;
 
- GC_CreateThread(NULL, 0, really_start, info, 0, &id);
+ data->handle = GC_CreateThread(NULL, 0, really_start, info, 0, &id);
 _Jv_ThreadSetPriority(data, thread->getPriority());
 }
Index: include/win32-threads.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/include/win32-threads.h,v
retrieving revision 1.9
diff -u -2 -r1.9 win32-threads.h
--- include/win32-threads.h	21 Oct 2003 04:46:19 -0000	1.9
+++ include/win32-threads.h	8 Sep 2004 13:13:07 -0000
@@ -14,4 +14,5 @@
 #define __JV_WIN32_THREADS__
 
+#define WIN32_LEAN_AND_MEAN
 #include <windows.h>
 
@@ -76,4 +77,5 @@
 //
 
+#define _Jv_HaveCondDestroy
 int _Jv_CondWait (_Jv_ConditionVariable_t *cv, _Jv_Mutex_t *mu, jlong millis, jint nanos);
 void _Jv_CondInit (_Jv_ConditionVariable_t *cv);
Index: java/lang/natThread.cc
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/lang/natThread.cc,v
retrieving revision 1.27
diff -u -2 -r1.27 natThread.cc
--- java/lang/natThread.cc	28 May 2004 18:53:04 -0000	1.27
+++ java/lang/natThread.cc	8 Sep 2004 13:13:09 -0000
@@ -79,4 +79,10 @@
 natThread *nt = (natThread *) ptr;
 _Jv_ThreadDestroyData (nt->thread);
+#ifdef _Jv_HaveCondDestroy
+ _Jv_CondDestroy (&nt->join_cond);
+#endif
+#ifdef _Jv_HaveMutexDestroy
+ _Jv_MutexDestroy (&nt->join_mutex);
+#endif
 }
 
