dotgnu-general
[Top][All Lists]
Advanced

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

Re: [DotGNU]questions about the code


From: Rhys Weatherley
Subject: Re: [DotGNU]questions about the code
Date: Wed, 5 Mar 2003 07:32:36 +1000
User-agent: KMail/1.4.3

On Wednesday 05 March 2003 03:55 am, imateos wrote:

> 1) The macros for generating x86 code are in the file "x86_codegen.h",
> but when are they called??. Once the IL code has been translated to CVM,
> the function "_ILCVMInterpreter" is called, but what goes on?? The only
> actions that are made in the diferent cvm*.c files are referent to
> modify the stack an the PC, but no x86 code is generated.

The "unroll_method" instruction is placed at the front of the CVM method by 
the CVM coder.  When executed, it unrolls the code using "unroll_x86.c".  
Once finished, the "unroll_method" instruction is replaced with a jump to the 
unrolled code.

> 2) When the image is loaded into memory by the function
> "ILExecProcessLoadImage", after the loading it seems that we've got the
> metadata information duplicated? I tell this because we can find it in
> tokenData[] and image->data . it would be possible to delete some
> information from the image structure to optimize space??

The data in "image->data" is stored using the compressed metadata token 
representation, which is inconvenient to use at runtime.  The "tokenData[]" 
array points at parsed structures, ready to use.

Keep in mind that "image->data" is almost always mmap'ed.  What this means is 
that after the initial load phase, the metadata pages probably won't be 
touched again.  The kernel will gradually discard them from memory during 
paging activity (on a decent OS with virtual memory support).

I'm working on changes to the system that will convert tokens from the 
"image->data" format to "tokenData[]" on the fly as tokens are used, rather 
than all at once at startup time.  This should reduce memory requirements for 
the token table considerably, but it will lose some of the kernel page 
discard benefits as "image->data" will be accessed more frequently.  It 
remains to be seen how these two issues will trade off against each other.

Cheers,

Rhys.



reply via email to

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