|
From: KJK::Hyperion <no...@li...> - 2004-03-23 18:04:14
|
At 08.16 23/03/2004, Jeremy Fitzhardinge wrote: >Yes, but there is the issue of simply running out of address space. The >numbers you mention below suggest that there's less that 2G of address >space for applications under Windows, which means that if the client is >sharing the address space with shadow data, there is less than 1G for the >client's own use. most applications I've seen (including heavyweights like Opera with dozens of tabs and huge link/tab history files) never require more than half of the address space. I've verified this experimentally with a small program I've written that plots the virtual memory map of a given process. In general, the highest portion of the address space is taken by system DLLs and system data such as the PEB and TEBs, the portion slightly below it by other DLLs, and the lowest by nearly everything else (heaps, stacks, mapped shared memory, the main executable, etc.) They say a picture tells a thousand words, so I've attached a sample output. It shows the memory usage of the aforementioned instance of Opera, 1 pixel per memory page. The colors: black is free memory, yellow is DLL-mapped memory (the yellow bar at the top is the main executable), green is anonymous virtual memory (dark if reserved but not committed) and red is mapped memory (dark if mapped from a file). Addresses increase from top to bottom and from left to right. The lowest address is 0x00010000 and the highest 0x7FFEFFFF Anyway, note the *large* black space in the middle. Now, consider that this is an anomaly. The second largest virtual memory space on this machine (the instance of Eudora I'm typing this e-mail in) has *way* more than half of the address space free, in a nice contiguous block in the middle. Other things to consider are that 1) all DLLs are relocable, so those yellow bars you see could easily be moved up or down should necessity arise, that 2) reserved anonymous memory (dark green) can be considered to all practical effects free (is the shadow memory sparse?) and that 3) to 'grind *really* memory-consuming applications you can always boot with the /3GB kernel switch (it does what it sounds it does) >>Anyway, how do tools register with the JIT engine so they are called at >>certain points? >Um, well, they get to instrument the code as it goes through the JIT. so they are linked statically? >There's also special callbacks for things like allocations, but the >majority is done with >instrumentation. hmmm. I'll have to get back at this, when I have some more time >Julian's internals document is still a reasonable start for the overall >design, though many of the details have changed. Using --trace-* options >will give you some idea about what's going on inside. It isn't wildly >complex, but there are a lot of details. cool. I'll try as soon I can >Well, for each application level thread, Valgrind creates a kernel thread >in order to deal with blocking syscalls. perfect >Well, that's only about 2G. Typically under linux, the client address >space is from 0-3G (though it can be different for different kernel >configurations). it's not the default for Windows, but it's supported. It has a problem in that, even when enabled, a certain flag must be set in the main executable for the address space to be really 3GB, but I know a way to work around that |