[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