dotgnu-libjit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Dotgnu-libjit] Leaking of one struct jit_thread_control per thread.


From: GARCIA DE SORIA LUCENA, JUAN JESUS
Subject: [Dotgnu-libjit] Leaking of one struct jit_thread_control per thread.
Date: Tue, 27 May 2008 17:04:02 +0200

Hello everyone.
 

The servers where we run libjit are long-standing servers that create a
new thread per each request received. These service threads are not
reused; once they end serving the request they are destroyed, and a new
one is created when a new request arrives.
 
After looking at some memory leaks we had on those processes, we found
out that, apart from the function signature leak for which I've
previously submitted a patch, libjit is leaking one instance of struct
jit_thread_control for each thread that ends its execution.
 
It seems that a new instance of that struct is dynamically created and
stored at a TLS key the first time it's required in a given thread.
However, no cleanup (jit_free()) of that struct instance is done once
the thread ends.
 
I've looked at the problem. I think that when using pthreads, this can
be fixed by calling pthread_cleanup_push(jit_free, control) just after
the struct gets allocated. But right now we run this code in win32
servers, and I've not been able to find out how to do the same as
pthread_cleanup_push (kind of per-thread atexit()) in Windows.

After looking at these web pages,
 
        http://msdn.microsoft.com/en-us/library/ms682583(VS.85).aspx

        http://msdn.microsoft.com/en-us/library/ms682596(VS.85).aspx


it seems that, for win32, we could implement DllMain and do the
following:

 * Move init_win32_thread() contents (creation of the JIT global lock
and allocation of the TLS index) to DLL_PROCESS_ATTACH time.
_jit_thread_init() would become a no-op for win32 thus.

 * Implement currently missing deallocation of the TLS index at
DLL_PROCESS_DETACH time.

 * Free the struct jit_thread_control instance for the current thread
(if not null) at DLL_THREAD_DETACH time.



If you think this is the right approach, please tell me and I can
prepare a patch.


Regards, and thanks in advance,

   Juan Jesus.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]