C++博客-T9的空间 -随笔分类-Useful information

Linux memory summary

Torres — Mon, 09 Dec 2013 09:42:00 GMT

From Unix某论坛，忘记名字了...但这段文字从宏观上讲清楚了Linux Memory的构架。
1. 内核初始化：

* 内核建立好内核页目录页表数据库，假设物理内存大小为len，则建立了[3G--3G+len]::[0--len]这样的虚地址vaddr和物理地址paddr的线性对应关系；
* 内核建立一个page数组，page数组和物理页面系列完全是线性对应，page用来管理该物理页面状态，每个物理页面的虚地址保存在page->virtual中；
* 内核建立好一个free_list，将没有使用的物理页面对应的page放入其中，已经使用的就不用放入了；

2. 内核模块申请内存vaddr = get_free_pages(mask,order)：

* 内存管理模块从free_list找到一个page，将page->virtual作为返回值，该返回值就是对应物理页面的虚地址；
* 将page从free_list中脱离；
* 模块使用该虚拟地址操作对应的物理内存；

3. 内核模块使用vaddr，例如执行指令mov(eax, vaddr)：

* CPU获得vaddr这个虚地址，利用建立好的页目录页表数据库，找到其对应的物理内存地址；
* 将eax的内容写入vaddr对应的物理内存地址内；

4. 内核模块释放内存free_pages(vaddr,order)：

* 依据vaddr找到对应的page；
* 将该page加入到free_list中；

5. 用户进程申请内存vaddr = malloc(size)：

* 内存管理模块从用户进程内存空间(0--3G)中找到一块还没使用的空间vm_area_struct(start--end)；
* 随后将其插入到task->mm->mmap链表中；

6. 用户进程写入vaddr(0-3G)，例如执行指令mov(eax, vaddr)：

* CPU获得vaddr这个虚地址，该虚地址应该已经由glibc库设置好了，一定在3G一下的某个区域，根据CR3寄存器指向的current->pgd查当前进程的页目录页表数据库，发现该vaddr对应的页目录表项为0，故产生异常；
* 在异常处理中，发现该vaddr对应的vm_area_struct已经存在，为vaddr对应的页目录表项分配一个页表；
* 随后从free_list找到一个page，将该page对应的物理页面物理首地址赋给vaddr对应的页表表项，很明显，此时的vaddr和paddr不是线性对应关系了；
* 将page从free_list中脱离；
* 异常处理返回；
* CPU重新执行刚刚发生异常的指令mov(eax, vaddr)；
* CPU获得vaddr这个虚地址，根据CR3寄存器指向的current->pgd，利用建立好的页目录页表数据库，找到其对应的物理内存地址；
* 将eax的内容写入vaddr对应的物理内存地址内；

7. 用户进程释放内存vaddr，free(vaddr)：

* 找到该vaddr所在的vm_area_struct；
* 找到vm_area_struct:start--end对应的所有页目录页表项，清空对应的所有页表项；
* 释放这些页表项指向物理页面所对应的page，并将这些page加入到free_list队列中；
* 有必要还会清空一些页目录表项，并释放这些页目录表项指向的页表；
* 从task->mm->mmap链中删除该vm_area_struct并释放掉；

综合说明：

* 可用物理内存就是free_list中各page对应的物理内存；
* 页目录页表数据库的主要目的是为CPU访问物理内存时转换vaddr-->paddr使用，分配以及释放内存时不会用到，但是需要内核内存管理系统在合适时机为CPU建立好该库；
* 对于用户进程在6中获得的物理页面，有两个页表项对应，一个就是内核页目录页表数据库的某个pte[i ]，一个就是当前进程内核页目录页表数据库的某个 pte[j]，但是只有一个page和其对应。如果此时调度到其他进程，其他进程申请并访问某个内存，则不会涉及到该物理页面，因为其分配时首先要从 free_list中找一个page，而该物理页面对应的page已经从free_list中脱离出来了，因此不存在该物理页面被其他进程改写操作的情况。内核中通过get_free_pages等方式获取内存时，也不会涉及到该物理页面，原理同前所述。

Torres 2013-12-09 17:42 发表评论

高性能JNI

Torres — Mon, 09 Dec 2013 09:40:00 GMT

from: http://www.cnblogs.com/whjiang/articles/1387364.html

1. 尽可能不要创建global reference和global weak reference. 创建这两类引用的JNI接口NewGlobalReference和NewGlobalWeakReference内部实现
有一个锁。这个锁使得在多处理器上的可扩展性非常差，因为各个线程都在等待这个锁。所以尽量不要在native保存java 对象的引用，情愿在每次
JNI call时都带点参数。当然，在native保持java对象的local reference是非常危险的，绝对不能那样干。

2. 尽量不要使用GetPrimitiveArrayCritical/ReleasePrimitiveArrayCritical来pin住Java内存。JVM本身没有提供任何只pin住一块Java内存而不影
响GC的操作，所以这个操作是会阻止GC进行的。作为补偿，ReleasePrimitiveArrayCritical会产生一次隐式的GC调用。这样就可能出现在需要GC的时
候无法GC，而在不需要GC时进行无意义GC的情况。另外，这两个操作的实现中在某些情况下也可能触发锁。解决方法：如果是小块内存的话，情愿使
用GetArrayRegion和SetArrayRegion来在native和Java之间复制内存。

3. 在Java appliation中尽量不要创建phantom reference或者soft reference。这些reference会极大的影响GC。
我们先来谈谈JVM的GC。GC分为minor GC和full GC。Java内存分为young和old两代。在young memory中，每个线程都有自己的内存分配块（不和其它
线程共享），而old memory是由所有线程共享的。minor GC只对young memory作GC，而full GC对所有内存都做GC。minor GC是可以多线程并行进行的
，而full GC默认只能单线程执行。所以，一次full GC需要的时间可以是minor GC是10倍以上（可以用-verbose:gc观察）。所以在一般应用中，
minor GC的次数应该是full GC的10倍左右是比较理想的。minor GC会将无法收集的对象移动到old memory中去。

minor GC不会对phantom reference和soft reference进行收集，只有full GC才会。这样的问题就是大量的这类对象积聚起来，产生许多的内存复制。

这样每次minor GC可能就基本上没有释放多少内存，使得full GC就会被频繁触发。可能出现minor GC和full GC次数1：1的情况，甚至全是full GC。

这样，无论是性能还是可扩展性都是非常差的。

weak reference的影响好像小一些，但也应该尽量避免。

在JNI开发中，使用这3种reference的主要目的是保证native资源的释放。因为java对象的finalize方法是不保证被调用的，所以必须用这些

reference来帮助实现native资源释放。为了避免上述的问题，一种可行的方法是将native资源serialize成一块内存，然后放到java对象中保存，从
而避免使用这些reference。

4. NIO是不错的Java和native之间share memory的方法。但要注意它的性能。首先一定要设置对big endian还是little endian，防止JVM做额外的
endian转换动作。其次是在启动JVM时一定要加上-server选项，否则nio性能会非常差。在-server mode下，nio性能大概比java数组慢30%~50%.在-
client mode下，性能差1倍以上。

5. 尽量不要在JNI去new Java String对象。这个比在java层new慢很多。

6. 对java大对象（比方说数组），一定要仔细的tune他的大小。一般来说，小对象对GC比较友好。因为对象分配时先看每个线程自己的young memory
，如果找的到足够大的内存的话，就分配。否则在old memory中分配。因为old memory是shared，所以可能有锁开销。而且old memory中的对象只有
full GC才能释放它。所以对象比较小是比较好的。JVM的内存分配算法是为小对象优化过的，大量小对象的分配是很高效的，所以不用怕把大对象拆小。
在某些情况下，如果知道对象会活的很久的话，就让它大一点，增加它直接分配在old memory中的概率。这样可以节约young GC拷贝这个对象到old

memory中的开销。

Torres 2013-12-09 17:40 发表评论

ACM OJ Collection

Torres — Tue, 09 Sep 2008 13:20:00 GMT

摘要: 这是在一个百度贴吧里转载的OJ及有用的网址收集！阅读全文

Torres 2008-09-09 21:20 发表评论