[Mono-dev] When does JIT reuse memory for new methods

Andreas Nahr ClassDevelopment at A-SoftTech.com
Sun Feb 18 20:13:56 EST 2007


I might be wrong on that one, but afaik method-definitions are only unloaded
once the AppDomain gets unloaded (or should be - not sure if mono already
does this)

 

Andreas

 

  _____  

Von: mono-devel-list-bounces at lists.ximian.com
[mailto:mono-devel-list-bounces at lists.ximian.com] Im Auftrag von Muath A.
Khalaf
Gesendet: Montag, 19. Februar 2007 00:43
An: mono-devel-list at lists.ximian.com
Betreff: [Mono-dev] When does JIT reuse memory for new methods

 

Hi,
I am trying to output some memory map files for mono JITed methods. 
I have managed to find the place where methods are JITed and output a file 
with the starting address of each method and the size (was easy).
Now I am trying to find the place where a memory chunk allocated for a
method by 
the JIT is reused for another method when JIT runs out of memory. I have
seen that
 all JITing is done in a memory pool temporarily and then a code manager
(for each
 domain) is used to find a chunk with a space for the new code or allocate 
a new one. One thing I did not get is that code manager always allocates a
new 
chunk and never delete previous filled chunks. Instead they are moved to the
full
 list. So where exactly is the place where JIT starts to free some memory
for new
 methods. Also what about the reJITed methods? what happen to the previous
code
 memory place. This is important for me to decide when should I stop filling
a memory 
map and start with a new one so that I do not mix different methods with the
same 
memory addresses.
Thanks


Muath

 

  _____  

Need a quick answer? Get one in minutes from people who know. Ask your
question on Yahoo!
<http://answers.yahoo.com/;_ylc=X3oDMTFvbGNhMGE3BF9TAzM5NjU0NTEwOARfcwMzOTY1
NDUxMDMEc2VjA21haWxfdGFnbGluZQRzbGsDbWFpbF90YWcx>  Answers.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070219/66f0d24d/attachment.html 


More information about the Mono-devel-list mailing list