[转]32位 s 64 位

Objective(目标)

Theintention(意图)of this article is to assist the readers realize(了解)why a same piece of code when executed on 32 bitenvironment,WOW(Windows on Windows) environment and 64 bitenvironment,consumes different amounts of memory.

Introduction

It'sknown and evident(明显)that running an application over WOW consumes more more memory than32 bit and running it on 64 bit consumes more than WOW and 32 bitenvironment.

Althoughthere is no definite(确定的)formula to find out the exact percentage increase in memory,the belowdiscussion,by comparing 32 bit against 64 bit and 32 bit against WOW,helps understand what causes the memory usage(用法)to increase.

Background

Readerwho has the basic knowledge of WOW,32 bit application,64 bitapplications and platform porting background would make the most ofthis article.

Tobe on the safer side,if you decide to go through this article in anycase,let us summarize WOW in one line.

"WOWsimulates(模仿)an environment of a different platform than the one which is sittingbeneath(在…之下),sothat,an application which would have otherwise beenincompatible(不兼容的)will now run."

32bit Vs 64 bit

Theprimary change between 64 bit and 32 bit is the width of addressfield,which has increased to 8 bytes from 4 bytes.So,evidently,morethe number of address fields\pointers in our application,moreis the memory consumption(消耗)in 64 bit. This document is as an exercise to traverse(详细研究)through a .Net process and explore(探索)all the underlying(潜在的，根本的)address fields/ pointers, present at different places with in aprocess, which ultimately(根本,基本上)remains(保持)responsible for the increase in memory consumption in a 64 bitprocess over a 32 bit process.

Data Alignment(数据调整)

One of theprimary(主要的)reasons for the increase in memory is Data alignment. Data alignmentis putting the data at a memory offset which is a multiple(倍数)of the "WORD" size.

When aprocessor(处理器)reads from or writes to the memory, it is in "WORD" sizedchunks(块)which is, 4 bytes in a 32 bit environment and 8 bytes in a 64 bitenvironment. When the size of a given object doesn't make up to themultiple of "WORD", the operating system will have to makeit equal to the size of the very next multiple of "WORD".This is done by adding some meaningless information (Padding) at theend of the object.

In a 32 bit.Net process, the size of an object is at least 12 bytes and in a 64bit .Net process, it is at least 24 bytes. The header which consistsof two pointer types takes away 8 bytes and 16 bytes respectively in32 and 64 bit environment. Even if the object doesn't have anymembers with in it, it consumes those additional 4 bytes \ 8 bytesfor padding purpose which makes it's size 12 and 24 respectively in32 bit and 64 bit process.

在32位的.Net进程中，对象至少有12个字节；而在64位的.Net进程中，至少24个字节。由两个指针组成的头部从32位和64位的环境中消耗8个和16个字节。即是对象本身不包含任何成员，它也会因为填充的目的消耗附加的4个或者8个字节，从而使得在32位和64位进程中大小为12个或者24个字节。

If an object in32 bit environment having only one member which is short, the size ofthat object should be ideally(理想地)size of header(8 bytes) + size of short (2 bytes). But, it ends upbeing size of the header (8bytes) + size of short (2 bytes) + paddingbytes (2bytes) and hence(因此)data alignment leads to unavoidable(不可避免的)wastage of memory. This wastage gets exaggerated(夸张)in 64 bit environment simply because the WORD size becomes 8 bytesinstead of 4 bytes. If an object in 64 bit has just one member whichis a short it would take 24 bytes (16 bytes of header + 2 bytes ofshort + 6 bytes of padding \ adjustment). The wastage \padding is nota constant(恒定的)factor in each object instead it depends on the ‘Type’ and‘Number’ of members of that object.

Eg: The objectwhich contains just one‘int’ and pays 24 bytes could have had 2‘int’s at the same cost resulting in zero wastage. An objectwhich contains just one ‘short’ at the cost of 24 bytes couldhave 4 ‘short’s at the same cost and zero wastage.

Object Header(对象头)

Any .NET objectwould have a sync(同步)block (pointer to a sync block) and a type handler-处理器(Method table pointer). The headersize increases by 8 bytes in 64 bit since the header essential hastwo pointers and pointer in 64 bit is 8 bytes against 4 byte in 32bit environment. This means, if an application has 10000 objects (beit of any type) the memory straight away increases by 80,000 bytesbetween 32 and 64 bit environments, even if they are blank objects.

任何.NET对象都有一个同步锁(同步锁指针)和一个类型处理器(方法表指针)。在64位中头部大小会增加8个字节由于头部的基本中有两个指针并且指针在64位环境中是8个字节而在32位中是4个字节。这意味着，如果一个对象中有10000个对象(任何类型)，在64位的环境中内存会一下子比32位增加80000个字节，即是他们都是空的对象。

The Stack

Thestack segment(段，部分)of the process does contribute(贡献)to the increase in memory in 64 bit as well. Each item \line in astack has two pointers one for the callee(被调用者)address and the other being the return address. Just to get a feel ofhow significant(有意义的)it’s contribution is, let us consider the below program.

namespace Memory_Analysis{
    class Program{
        static void Main(string[] args){
            A obj = new A();
            Console.ReadLine();
        }
    }
    class A{
        char Data1;
        char Data2;
        short Data3;
        int Data4;
    }
}

Thestack segment for this code when executed would be having around 6000lines(Measured by SOS). 6000 lines would result in 1200 addresses(pointers) fields because, as said above, each line in the stackwould have two addresses a callee and a return address. Each addressfield leads to an increase of 4 bytes in 64 bit. So there will be anincrease of (1200 * 4) 4800 bytes in the stack segment itself for thecode segment which is as small as above.

这个代码的堆栈段杂执行时将会有大约6000行(用SOS衡量)。6000行将会导致1200个地址域(指针)，就像上面提到的，在堆栈中的每一个都有一个两个地址(调用地址和返回地址).每个地址域会在64位环境中引起4位的增加.即是像上面这样小的代码，也会在堆栈段本身中增加4800个字节(1200*4)。

Method Table(方法表)

Now coming tothe method tables, each class which has at least one live instancewould have a method table. Each method table would again have 2address fields (entry point and description-类型).If an application has 100 methods including all the classes withinit, that would lead to ((100* 2) * 4) 800 bytes of increased memoryin 64 bit just because of the method tables. Similarly-类似的,others who have address fields and contribute to the memory increaseare GCHandles(garbage collection handler)and FinalizationQueue(??).

Assemblies(程序集)

Other than thestack and the heap, the assemblies that get loaded in to itsAppDomain also contribute to the increase in memory. Below is a snapshot(快照-memorysnap shot which can help us know the system state) of theheader of an AppDomain. As we can see, there are at least 15 addressfields in the header.

After theheader, the Appdomain would consist of a list of all the assemblieswithin the app domain. Under each assembly it again consists of alist of all the modules(模块)within that assembly.

Below is aportion(部分)of snap shot of the list of assemblies and the modules within eachassembly. The below snap shot contains only that portion of theAppDomain which has reference to our sample "Memory_Analysis"assembly.

TheAppDomain which loads our sample application "Memory_Analysis"has to also load all the referenced dlls from our sampleapplications, including the .Net dlls like MSCOREE.dll andMSCORWKS.DLL. For each such referenced DLL, there would be entriessimilar to(类似于)the one shown in the above snapshot.

Further tothis, within each module, there would be several address fields asmentioned below in the snapshot(快照)

Uponmeasuring using SOS & WinDBG(一种强大的系统调试工具，百度词条：http://baike.baidu.com/view/ 4448351.htm-词条的下方的网址有意思),a simple assembly like our "Memory_Anal-ysis"had around 80 address fields loaded in the AppDomain which means anincrease in memory by (80 * 4) 320 bytes . More the number ofreferenced assemblies and more the number of modules, higher will bethe memory consumption.

32bit vs. WOW

After havingcompared 32 bit Vs 64 bit, let us now explore(探索)the differences between running a 32 bit process on a 32 bitenvironment and running a 32 bit process on a WOW environment.

WOW (Windows onWindows) as we know, is a simulated environment where a 64 bitOperating system provides a 32 bit environment so that the 32 bitprocesses can run seamlessly(无缝的).The trigger(触发)point to this discussion is the fact that, running a 32 bit processon WOW takes more memory than running a 32 bit process on 32 bitenvironment. The discussion below, tries to explore some of thereasons why running on a WOW ends up consuming more memory. Beforefinding out the reasons for hike(提高，上升)in memory, it is important to realize the magnitude(量级)of hike. Yet again there is no formula(公式)to find out the exact percentage increase in memory when run on WOWmode. Nevertheless, an example and some explanation might help usrealize the magnitude of increase. Let us consider the below piece ofcode.

class MemOnWOW{
    int i;
    private MemOnWOW() {
        i = 10;
    }
    static void Main(string[] args){
        MemOnWOW p = new MemOnWOW();
        System.Console.ReadLine();
    }
}

This when builtfor a 32 bit platform and executed in a 32 bit environment consumes atotal size of 80,596 KB and when executed over a WOW environment,consumes a total size of 115,128 KB, which means an increment of34,532 KB. ** Total size: Total size includes Managed heap(托管堆),Unmanaged Heap(非托管堆),Stack, Image, Mapped Files, Shareable, Private data and Pagedtables(页表).Now, let us list down the contribution to the increase in memory byeach of the segments within the total memory.

WOW Images and execution engine

The assembliesof the WOW, which are located at the location C:\windows\sysWOW64,add up to the increase in memory by around 12MB. These assemblies arerequired to bring up(提出)and execute the WOW environment within which the 32 bit process runs.Below is the list of some of the Dlls which are required to bring upthe WOW environment and their roles.

• Wow64.dll

Manages processand thread creation. Exception dispatching File system redirectionRegistry Redirection(托管进程和线程的创建，异常调度，文件系统调用重定向，注册表重定向)

• Wow64Cpu.dll

Manages(管理，空提)the 32-bit CPU context(上下文)of each running thread inside Wow64. Provides processorarchitecture-specific(特定架构)support for switching CPU mode from 32-bit to 64-bit and viceversa(反之).

• Wow64Win.dll

Intercepts(拦截)the GUI system calls.

It is importantto understand the overhead added by WOW execution environment. Youmay want to go through the detailed explanation given by MarkRussinovich in his book Windows Internals.

Whenever thereis a system call which is made to the underlying(根本的)kernel (Call to the API exposed-暴露的by the kernel) or whenever there isa call back from the kernel, the input parameters and outputparameters have to be converted from 32 bit to 64 and 64 to 32 bit.

Wow which sitsin between has the responsibility of converting the 32 bit user modeobject to 64 bit user mode object before sending it to the kernel.Similarly, WOW will also have to convert 64 bit kernel objects to 32bit kernel object before presenting it to the 32 bit userapplication. Similar conversions(相似的转换)do take place when the kernel throws an exception object and it hasto reach the user application. This is also called as "Exceptionhooking \ Exception Dispatching". Evidently-显然,in the scenarios(情节)explained above where there are additional intermediate-中间的(userand kernel) objects created, memory is bound(限制，约束)to increase. These conversions between kernel and user mode can alsolead the performance degradations(降质)and not just the memory increase.

Mapped Files

During theexecution of a .Net application there could be several files whichget memory mapped(内存映射).Some of them are the globalization(全球化)files (*.nls), font files (*.ttf) etc. When run under WOW, there areadditional WOW related files which gets memory mapped and hence(因此)leading to memory hike(上升).The number of files which gets memory mapped depends on the kind ofassemblies referenced, resources used within the application etc. Forthe example "MemOnWOW" that we have considered above, theadditional mapped files in the WOW mode are the globalization related.nls files which consume(花费)around 2.5 MB of excess(过量的)memory.

Unmanaged Heap-use by WOW environment

Under the WOWexecution, the unmanaged heap would be used by the WOW environment.In our current example, it consumes around 2 MB of the processmemory. This unmanaged heap would never be used when a 32 bit managedapplication is run directly under 32 bit environment.

Managed Heap

Managed heapwould be kind enough to stay neutral(中性的)and consume exactly(准确的)the same amount of memory, whether it is WOW or direct 32 bitenvironment.

Private Data-consume constant memory if application hasprivate data

Private dataworth around 18 MB is added to the total memory size of the processwhen run under WOW, because of it being in WOW mode. If there areadditional private data because of the application itself, it wouldbe in addition to this 18MB (in WoW).

Stack Segment--must maintain 2 different independentstack

Thestack’s contribution to the increase in memory, when run over WOW,varies(改变)from application to application as it depends on the program length(how long the stack is). As we know, Stacks are used to storefunction parameters, local function variables and functioninvocation-调用records (who has invoked thefunction) for individual(独立)threads. If there are 3 threads, there would be 3 different stacks inthe stack segment.

Whenrun under WOW, for each thread the stack segment would have tomaintain 2 different and independent stacks one as the 32 bit stackand the other as a 64 bit stack. So, if there are 3 threads in anapplication, there would be 6 different stacks in the stack segmentwhen run on WOW.

References

·WMMAPDocumentation

·WindowsInternals by Mark Russinovich

·blogs.Technet.com--thisa good website,there are many NB people in it.

License

Thisarticle, along with any associated source code and files, is licensedunderTheCode Project Open License (CPOL)

转自:  32 bit vs. 64 bit memory -http://www.codeproject.com/Articles/526984/32-bit-vs-64-bit-memory