看understanding linux kernel的一点笔记：
页表
通常32位cpu使用2级页表机制就已足够，但到64位时代，2级页表会使页表的项急剧增加，所以通常会使用更多的页表级数。
ia64/ppc64/alpha使用3级页表，x86_64使用到4级页表。为兼容这些模型，2.6.11之后使用了统一的4级页表模型
Global Directory
Upper Directory
Middle Directory
Page Table
针对不同的架构，设置每一级不同的地址位数，0的话就是不使用这一级页表机制。

cache
多cpu环境中，每个cpu有自己的cache，对cache的更新有硬件机制保证通知其他的cpu进行同步。(真的吗?)

tlb
用来cache页表，加速地址的转换速度。每个cpu有自己的tlb，但不需要同步，因为地址转换和进程相关。

LinuxThreads:
  旧的pthread实现，基于process实现pthread。主要问题是signal不符合规范，stack size固定???

NPTL:
  2.6后加入的新实现，redhat as中2.4就可以支持。更符合pthread的规范。用户线程和内核线程采取1:1模式，支持floating stack。

今天花了一点时间作了个x86上hotspot vm的disassembler，这样可以看出jvm生成的本地代码了。
代码比较简单，主要是用了udis86的库，这个可以在sf上下载到，它的接口还是比较简单的。

简单的例子，hotspot解析模式中iconst_0的对应汇编代码：
iconst_0  3 iconst_0  [0xb4d98120, 0xb4d98160]  64 bytes

  0xb4d98120: sub esp, 0x4
  0xb4d98123: fstp dword [esp]
  0xb4d98126: jmp 0x1e
  0xb4d9812b: sub esp, 0x8
  0xb4d9812e: fstp qword [esp]
  0xb4d98131: jmp 0x13
  0xb4d98136: push edx
  0xb4d98137: push eax
  0xb4d98138: jmp 0xc
  0xb4d9813d: push eax
  0xb4d9813e: jmp 0x6
  0xb4d98143: push eax
  0xb4d98144: xor eax, eax
  0xb4d98146: movzx ebx, byte [esi+0x1]
  0xb4d9814a: inc esi
  0xb4d9814b: jmp dword near [ebx*4+0x6900680]

对soft reference，比较容易理解它的用处。它天生就是为实现cache来设计的。关于weak reference，好像很少有人说的清楚。有的和soft reference混在一起谈，有的就是简单翻译java doc中的说明，看得出翻译的人自己也不是很理解，所以只能一笔带过。

我也一直不是很清楚它的实际用途，今天我突然想到WeakReference可能的设计目的。

从java的内存泄漏说起，以前说到java也会内存泄漏的时候往往会举这样的例子，对象保存在一个全局表中，造成无法回收。一般的解决方法是不要使用全局表或者记得更新。但在实际开发中，有时必须要使用全局表，但无法明确知道该对象是否可销毁，因为对象可能被多个线程共享访问，所以程序不能确切的更新表中的引用。这时候weak reference就有用武之地，用WeakHashMap构造全局表，key和value之间是weak reference，这样的话程序员就不用考虑更新该表了，只要该对象没有强引用指向它，gc就可以回收它了。

回头去找一个实际的例子对照看看，记得在JDK中，weak reference还是用的很频繁的。

以前用redhat的时候使用rpm管理软件包，因为不能解决软件的依赖关系后来转到debian。apt确实方便了很多，但一直怀念rpm的一个功能，rpm可以查询一个文件具体属于哪个包，用apt一直没有找到对应的命令。
今天想在64位ubuntu上编译32位程序的时候发现没有/usr/include/gnu/stub-32.h，在网上搜索时突然发现apt也可以根据文件来搜索包。命令是apt-file(缺省是没有安装的)。
先安装apt-file
使用apt-file update同步安装包内部的文件，它会到你定义的source去获取这些信息，运行会比较慢，而且没有什么提示，不知道今后会不会都是这样。
然后就可以用apt-file find xxx 去查询了。


－每天进步一点点， :)