s****y
发帖数: 503 | 1 这两天有个Java的面试，job description里有句Understanding of different OS
Memory management strategies and heap structure，只是什么意思？我应该看些什
么做准备呢？ |
k**********g
发帖数: 989 | 2
你的描述和 Oracle 的文档很相近，要面 Oracle 吗？
https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/
garbage_collect.html
just from google search result, first link.
【在 s****y 的大作中提到】
: 这两天有个Java的面试，job description里有句Understanding of different OS
: Memory management strategies and heap structure，只是什么意思？我应该看些什
: 么做准备呢？
|
s********k
发帖数: 6180 | 3 Java需要知道这么底层的吗？heap structure看OS的教科书，或者简单点，能把malloc
搞清楚底层是怎么分配memory的基本差不多了，不过这是C的范围了
【在 s****y 的大作中提到】
: 这两天有个Java的面试，job description里有句Understanding of different OS
: Memory management strategies and heap structure，只是什么意思？我应该看些什
: 么做准备呢？
|
g*****g
发帖数: 34805 | |
S*A
发帖数: 7142 | 5 OS Memory management strategies
是要在不同 OS 层面上说的，例如 page， mmap 之类的。 Java GC
说到底是个 application 层面上的，应该和 OS 不是一个 level。 |
d****i
发帖数: 4809 | 6 这个比较底层一点，可以看一下Linux的memory management，不知道为什么会在Java的
面试要求中，可能是指JVM的内部实现吧。OS level的内存管理可以看一下：
http://www.tldp.org/LDP/tlk/mm/memory.html
【在 s****y 的大作中提到】
: 这两天有个Java的面试，job description里有句Understanding of different OS
: Memory management strategies and heap structure，只是什么意思？我应该看些什
: 么做准备呢？
|
w***x
发帖数: 105 | 7 right
【在 S*A 的大作中提到】
: OS Memory management strategies
: 是要在不同 OS 层面上说的，例如 page， mmap 之类的。 Java GC
: 说到底是个 application 层面上的，应该和 OS 不是一个 level。
|
c****f
发帖数: 1102 | 8 memory managment heap唯一有关的javau应该就是gc了 不过这不是就一句话吗。。而
且heap唯一的结构不就是随意堆放 从后往前嘛 |
S*A
发帖数: 7142 | 9 我猜啊，公司希望可以知道比java底层的 OS 是如何玩这些的。
想问的是出现内存 swap storm 或者 memory leak 这
样的情况在 OS 这一层有什么可以做的，如何鉴别和调试。
你说的 heap 是很古老的玩法。现在 Linux 的 malloc 大一点或者多
一点的内存都是用 mmap 做的，以经不是 heap（brk syscall） 这种
单一方向增长的。64 位的虚拟地址很大，可以随便放。
如果你有多个thread， 每个tread有自己的 stack， 那个stack 就
没法一个一个和 heap 对接起来，因为有很多个。
【在 c****f 的大作中提到】
: memory managment heap唯一有关的javau应该就是gc了 不过这不是就一句话吗。。而
: 且heap唯一的结构不就是随意堆放 从后往前嘛
|
T********i
发帖数: 2416 | 10 其实我做realtime系统这么多年，都不知道linux的malloc咋实现的。
我的系统内存管理都是自己做的。其实只要要求利用率大于50%就可以，内存管理可以
guarantee几条指令完成的。
我创建thread的时候同时提供stack。我的系统没那么多递归。预留2Mstack估计100K都
用不到。
自己提供stack可以保证stack的memory和core在同一个NUMA node。性能稍高一点。
其实为了方便，我大量使用C++ STL。只需简单实现一个allocator就好了。我的
allocayor也是NUMA aware的。
【在 S*A 的大作中提到】
: 我猜啊，公司希望可以知道比java底层的 OS 是如何玩这些的。
: 想问的是出现内存 swap storm 或者 memory leak 这
: 样的情况在 OS 这一层有什么可以做的，如何鉴别和调试。
: 你说的 heap 是很古老的玩法。现在 Linux 的 malloc 大一点或者多
: 一点的内存都是用 mmap 做的，以经不是 heap（brk syscall） 这种
: 单一方向增长的。64 位的虚拟地址很大，可以随便放。
: 如果你有多个thread， 每个tread有自己的 stack， 那个stack 就
: 没法一个一个和 heap 对接起来，因为有很多个。
|
|
|
S*A
发帖数: 7142 | 11 您老说的是 C++ 吧，和 LZ 问的 java 有点不一样了。
我对 Linux 内核的memory 管理还比较熟悉的，user space glibc
是如何搞就知道不多了。
Free 不是固定大小的 allocation 是如何几条指令处理的？
要和旁边的 area merge 吧，我自己觉得那个不太容易几个
指令搞定。如果是 alloc/free 固定大小的 allocation，
那个很容易几个指令搞定。
你 override 了 C++ 的 “new”？这个好想是很麻烦的事情，有些
时候一些lib free memory 的时候去调用系统的 free 而不是你自
己的那个 free 然后就悲剧了。我以前碰到过这种情况，非常恶心。
你是如何解决的？
【在 T********i 的大作中提到】
: 其实我做realtime系统这么多年，都不知道linux的malloc咋实现的。
: 我的系统内存管理都是自己做的。其实只要要求利用率大于50%就可以，内存管理可以
: guarantee几条指令完成的。
: 我创建thread的时候同时提供stack。我的系统没那么多递归。预留2Mstack估计100K都
: 用不到。
: 自己提供stack可以保证stack的memory和core在同一个NUMA node。性能稍高一点。
: 其实为了方便，我大量使用C++ STL。只需简单实现一个allocator就好了。我的
: allocayor也是NUMA aware的。
|
T********i
发帖数: 2416 | 12 其实我的要求比较特殊。第一，dedicated application server。专机专用。第二，
memory不是问题，事实上所有page都是强制lock的。不可能swap。第三，大多数memory
allocation都是预先分配好的。永远不需要释放。第四，不需要实时的部分直接用STL
就好了。第五，需要一些实时的memory management。
因此我不需要overload new operator。我需要自己的STL allocator就好了。假定你不
太在乎动态内存的分配效率，做一个保证几条指令完成的方案易如反掌。
注意，我还假定内存肯定足够多。其实这个很容易保证。内存的上限也很容易证明。
这个架构其实能推广到任何应用。
【在 S*A 的大作中提到】
: 您老说的是 C++ 吧，和 LZ 问的 java 有点不一样了。
: 我对 Linux 内核的memory 管理还比较熟悉的，user space glibc
: 是如何搞就知道不多了。
:
: Free 不是固定大小的 allocation 是如何几条指令处理的？
: 要和旁边的 area merge 吧，我自己觉得那个不太容易几个
: 指令搞定。如果是 alloc/free 固定大小的 allocation，
: 那个很容易几个指令搞定。
: 你 override 了 C++ 的 “new”？这个好想是很麻烦的事情，有些
: 时候一些lib free memory 的时候去调用系统的 free 而不是你自
|
S*A
发帖数: 7142 | 13 说白了就是只 allocate， 不 free， 然后总数有限制。
这样其实不用 STL allocator， 随便 malloc 应该也一样。
反正你也不 free。大概区别就是 malloc 没有做 zone
optimization。
就算 malloc 不止几条指令，其实也无所谓，就一次，然后
总数有限。或者你自己 mmap，这个大概就最省了。
memory
STL
【在 T********i 的大作中提到】
: 其实我的要求比较特殊。第一，dedicated application server。专机专用。第二，
: memory不是问题，事实上所有page都是强制lock的。不可能swap。第三，大多数memory
: allocation都是预先分配好的。永远不需要释放。第四，不需要实时的部分直接用STL
: 就好了。第五，需要一些实时的memory management。
: 因此我不需要overload new operator。我需要自己的STL allocator就好了。假定你不
: 太在乎动态内存的分配效率，做一个保证几条指令完成的方案易如反掌。
: 注意，我还假定内存肯定足够多。其实这个很容易保证。内存的上限也很容易证明。
: 这个架构其实能推广到任何应用。
|
T********i
发帖数: 2416 | 14 哪有那么简单？只allocate不free是最底层的。上层的有能free的。
比如我最常用的binary allocator。每次都把size round up to nearest 2 n次方。这
样free都到一个free list里面，allocate先查free list。内存利用率低一点。但是保
证allocate和free都是纳秒级。
其它的各种allocator多了，比如object pool等等等等。有些我甚至都没看到其他人用
过。有很多都是自己拍脑门搞出来的。
有研究表明，一般而言一个server进程的70%-90%执行时间都消耗在memory management
上。因此，优化还是有必要的。
当然你可以argue有时free和allocate是上层比如STL vector reallocarlte导致的。随
后的memory copy更消耗时间。其实，很多时候我们可以保证reallocate不发生。但是
我们仍然有动态内存管理的需求。
【在 S*A 的大作中提到】
: 说白了就是只 allocate， 不 free， 然后总数有限制。
: 这样其实不用 STL allocator， 随便 malloc 应该也一样。
: 反正你也不 free。大概区别就是 malloc 没有做 zone
: optimization。
: 就算 malloc 不止几条指令，其实也无所谓，就一次，然后
: 总数有限。或者你自己 mmap，这个大概就最省了。
:
: memory
: STL
|
S*A
发帖数: 7142 | 15
allocate 都是要先看free list 能不能满足的。
你说这个应该 glib 就有把。用来 allocate 固定大小的 object 对吧。
management
这个要做 profiling。我自己直觉认为没有那么多，除非程序
写很烂。
【在 T********i 的大作中提到】
: 哪有那么简单？只allocate不free是最底层的。上层的有能free的。
: 比如我最常用的binary allocator。每次都把size round up to nearest 2 n次方。这
: 样free都到一个free list里面，allocate先查free list。内存利用率低一点。但是保
: 证allocate和free都是纳秒级。
: 其它的各种allocator多了，比如object pool等等等等。有些我甚至都没看到其他人用
: 过。有很多都是自己拍脑门搞出来的。
: 有研究表明，一般而言一个server进程的70%-90%执行时间都消耗在memory management
: 上。因此，优化还是有必要的。
: 当然你可以argue有时free和allocate是上层比如STL vector reallocarlte导致的。随
: 后的memory copy更消耗时间。其实，很多时候我们可以保证reallocate不发生。但是
|
w***x
发帖数: 105 | 16 malloc的算法，都被反复研究几十年了，自己再造这种轮子，意义不大吧。
不过我很好奇，什么样的server会“70%-90%执行时间都消耗在memory management” ？ |
S*A
发帖数: 7142 | 17 https://developer.gnome.org/glib/stable/glib-Memory-Slices.html
还是有意义的。例如上面说得 glib slice。
如果你经常 malloc/free 同样大小的 object。 就可以用
很快的 allocator。
？
【在 w***x 的大作中提到】
: malloc的算法，都被反复研究几十年了，自己再造这种轮子，意义不大吧。
: 不过我很好奇，什么样的server会“70%-90%执行时间都消耗在memory management” ？
|
w***x
发帖数: 105 | 18 类似slab的allocator？这类东西作为给stl的allocator倒是可以理解，但在malloc内
实现就没太大意义了吧。 |
T********i
发帖数: 2416 | 19
一般的allocator都复杂多了，而且不能保证determinism。我的简单但是速度快。
看来allocator如何工作的，我还没解释清楚：
假定我们规定内存分配最小16 bytes，最大4G。我的free list是一个32个指针的数组
。初始化都是NULL。
假定我们分配1000 bytes。我先round up to最近的2的n次方，1024bytes。是2的10次
方。free_list[10]是NULL。则从更底层分配1024 + 16 = 1040bytes。前面16 bytes是
meta data包含size and double linked list指针。返回此块的第16 bytes的指针就好
了。
free，就把指针减16，取得meta data。知道是一个1024 bytes块。就把这个块放到
free_list[10]的link list里面好了。
下次再分配1024 bytes，如果free_list[10]里面有，直接取出。
这样，内存浪费多一些。但是每次操作优势纳秒级别。
不知道有没有，反正我自己有。C++的template，顺便把initializer也一起call了。
而且NUMA aware的glib肯定没有。
这个统计也是据说。一般的程序写的都很烂。
【在 S*A 的大作中提到】
: https://developer.gnome.org/glib/stable/glib-Memory-Slices.html
: 还是有意义的。例如上面说得 glib slice。
: 如果你经常 malloc/free 同样大小的 object。 就可以用
: 很快的 allocator。
:
: ？
|
b*******s
发帖数: 5216 | 20 几个月前公司请了Scott Meyers来做了一个scalability的讲座，主要还是讲多核环境
下内存和cache的性能影响 |
|
|
T********i
发帖数: 2416 | 21 Cache agent具体如何工作好象是CPU厂商的技术机密。反正我曾试图搜索公开的文件未
果。
但是behavior知道一个大概也就行了。
【在 b*******s 的大作中提到】
: 几个月前公司请了Scott Meyers来做了一个scalability的讲座，主要还是讲多核环境
: 下内存和cache的性能影响
|
S*A
发帖数: 7142 | 22 求总结。
【在 b*******s 的大作中提到】
: 几个月前公司请了Scott Meyers来做了一个scalability的讲座，主要还是讲多核环境
: 下内存和cache的性能影响
|
w***g
发帖数: 5958 | 23 顺带分享一下我经常用的做法。有时候内存需求比较固定，就那么几个尺寸，我会一上
来就allocate几十G内存，然后切成需要的尺寸，用链表连成pool。之后运行时就全从
pool里出，再也不动态分配内存, 如果pool用光了就直接失败。一般来说服务器定了就
是干这个事的，这么多内存就跑这个服务，用不掉也没好处，用光了其实也没办法，还
不如一上来就分配了干净。这样provision起来也干净，运行时就用那么多内存，既不
会多也不会少。
malloc反正一直都是搞系统的优化的对象。
【在 T********i 的大作中提到】
: Cache agent具体如何工作好象是CPU厂商的技术机密。反正我曾试图搜索公开的文件未
: 果。
: 但是behavior知道一个大概也就行了。
|
T********i
发帖数: 2416 | 24 其实都是一码事。我的也是预先pre allocate几十G。
然后根据需要动态分。反正也就几十个不同尺寸。都是2的n次方。 free了就送回特定
的pool里面去。
其实很多优化都是简单的算法。只有简单算法效率才高。
这样做，能动态监视自己的pool的使用情况。便于profiling。如果启动几秒钟以后还
持续 allocate一般就是有memory leak了。
用光了就直接失败肯定是对的。甚至我的任何应用，都能够理论证明内存上限的。
【在 w***g 的大作中提到】
: 顺带分享一下我经常用的做法。有时候内存需求比较固定，就那么几个尺寸，我会一上
: 来就allocate几十G内存，然后切成需要的尺寸，用链表连成pool。之后运行时就全从
: pool里出，再也不动态分配内存, 如果pool用光了就直接失败。一般来说服务器定了就
: 是干这个事的，这么多内存就跑这个服务，用不掉也没好处，用光了其实也没办法，还
: 不如一上来就分配了干净。这样provision起来也干净，运行时就用那么多内存，既不
: 会多也不会少。
: malloc反正一直都是搞系统的优化的对象。
|
h****r
发帖数: 2056 | 25 you probably shall check the source code of latest tcmalloc, although it
still not ideal.
【在 w***g 的大作中提到】
: 顺带分享一下我经常用的做法。有时候内存需求比较固定，就那么几个尺寸，我会一上
: 来就allocate几十G内存，然后切成需要的尺寸，用链表连成pool。之后运行时就全从
: pool里出，再也不动态分配内存, 如果pool用光了就直接失败。一般来说服务器定了就
: 是干这个事的，这么多内存就跑这个服务，用不掉也没好处，用光了其实也没办法，还
: 不如一上来就分配了干净。这样provision起来也干净，运行时就用那么多内存，既不
: 会多也不会少。
: malloc反正一直都是搞系统的优化的对象。
|
w***x
发帖数: 105 | 26 感觉没什么必要，kernel就在做这种事情，除非你确定你的alloctor比kernel的vma实
现得更好。
【在 w***g 的大作中提到】
: 顺带分享一下我经常用的做法。有时候内存需求比较固定，就那么几个尺寸，我会一上
: 来就allocate几十G内存，然后切成需要的尺寸，用链表连成pool。之后运行时就全从
: pool里出，再也不动态分配内存, 如果pool用光了就直接失败。一般来说服务器定了就
: 是干这个事的，这么多内存就跑这个服务，用不掉也没好处，用光了其实也没办法，还
: 不如一上来就分配了干净。这样provision起来也干净，运行时就用那么多内存，既不
: 会多也不会少。
: malloc反正一直都是搞系统的优化的对象。
|
T********i
发帖数: 2416 | 27 很多时候，kernel是负担。
我的系统，24个core。给kernel两个core就不错了。其它的core kernel都看不见。
【在 w***x 的大作中提到】
: 感觉没什么必要，kernel就在做这种事情，除非你确定你的alloctor比kernel的vma实
: 现得更好。
|
w***g
发帖数: 5958 | 28 靠，这都可以。请展开说说
- 剩下的core怎么不让kernel看到?
- 怎么管理剩下的core?
【在 T********i 的大作中提到】
: 很多时候，kernel是负担。
: 我的系统，24个core。给kernel两个core就不错了。其它的core kernel都看不见。
|
b*******s
发帖数: 5216 | 29 CPU affinity binding, not that difficult
【在 w***g 的大作中提到】
: 靠，这都可以。请展开说说
: - 剩下的core怎么不让kernel看到?
: - 怎么管理剩下的core?
|
b*******s
发帖数: 5216 | 30 allow me to check out the PPT
【在 S*A 的大作中提到】
: 求总结。
|
|
|
w***g
发帖数: 5958 | 31 显然affinity binding也是kernel管的啊，离不被kernel看到差老远了。老魏可能有不
为人知的秘诀。
【在 b*******s 的大作中提到】
: CPU affinity binding, not that difficult
|
T********i
发帖数: 2416 | 32 不是真的看不着。而是假装看不着。可以保证kernel不会schedule任何job到那些core
上。
也就是说，给kernel两个core。这台机器就和dual core机器一样。剩下那些对kernel
和没有一样。
【在 w***g 的大作中提到】
: 显然affinity binding也是kernel管的啊，离不被kernel看到差老远了。老魏可能有不
: 为人知的秘诀。
|
w***g
发帖数: 5958 | 33 别的job schedule到哪儿无所谓。关键是kernel自己能限制在只在那两个core上跑吗？
kernel代码很多时候开销也不小。
core
kernel
【在 T********i 的大作中提到】
: 不是真的看不着。而是假装看不着。可以保证kernel不会schedule任何job到那些core
: 上。
: 也就是说，给kernel两个core。这台机器就和dual core机器一样。剩下那些对kernel
: 和没有一样。
|
b*******s
发帖数: 5216 | 34 hmm, you are right
sorry for misleading :)
【在 w***g 的大作中提到】
: 显然affinity binding也是kernel管的啊，离不被kernel看到差老远了。老魏可能有不
: 为人知的秘诀。
|
b*******s
发帖数: 5216 | 35 yup
【在 T********i 的大作中提到】
: Cache agent具体如何工作好象是CPU厂商的技术机密。反正我曾试图搜索公开的文件未
: 果。
: 但是behavior知道一个大概也就行了。
|
T********i
发帖数: 2416 | 36 能。
【在 w***g 的大作中提到】
: 别的job schedule到哪儿无所谓。关键是kernel自己能限制在只在那两个core上跑吗？
: kernel代码很多时候开销也不小。
:
: core
: kernel
|
b*******s
发帖数: 5216 | 37 some tips from SM's ppt
1) because we have optimized TLB. sometimes virtual is not as slow as what
we thought
2) if n is not that big. Linear search can beat O(logn) BST
3) false sharing is the worst thing when we have multiple cores
4) forward traversal and backward traversal are almost the same
5) hyper threading "cores" are sharing L1D and L1I
6) inline has its downsides
7) PGO and WPO
8) Cache-oblivious algorithm design.
9) Other cache technology issues:
Memory banks.
Associativity.
Inclusive vs. exclusive content. |
S*A
发帖数: 7142 | 38 1-5 我不用他说都很明白。
6 是说 inlined code size blow out code cache 吧，还有
其他的吗？
7 需要解释一下 PGO 和 WPO 是什么东西。
8 就是assume worse case always cache missing 吧。
如何设计 data structure 分布在尽量少的 cache line 里面。
9 这些user space编程几乎不太可能考虑这个方面的东西。
例如 memory bank 根本管不着。
【在 b*******s 的大作中提到】
: some tips from SM's ppt
: 1) because we have optimized TLB. sometimes virtual is not as slow as what
: we thought
: 2) if n is not that big. Linear search can beat O(logn) BST
: 3) false sharing is the worst thing when we have multiple cores
: 4) forward traversal and backward traversal are almost the same
: 5) hyper threading "cores" are sharing L1D and L1I
: 6) inline has its downsides
: 7) PGO and WPO
: 8) Cache-oblivious algorithm design.
|
T********i
发帖数: 2416 | 39 说实话，真的没啥干货。
【在 S*A 的大作中提到】
: 1-5 我不用他说都很明白。
: 6 是说 inlined code size blow out code cache 吧，还有
: 其他的吗？
: 7 需要解释一下 PGO 和 WPO 是什么东西。
: 8 就是assume worse case always cache missing 吧。
: 如何设计 data structure 分布在尽量少的 cache line 里面。
: 9 这些user space编程几乎不太可能考虑这个方面的东西。
: 例如 memory bank 根本管不着。
|
b*******s
发帖数: 5216 | 40 Profile-guided optimization (PGO)
Whole-program optimization (WPO)
【在 S*A 的大作中提到】
: 1-5 我不用他说都很明白。
: 6 是说 inlined code size blow out code cache 吧，还有
: 其他的吗？
: 7 需要解释一下 PGO 和 WPO 是什么东西。
: 8 就是assume worse case always cache missing 吧。
: 如何设计 data structure 分布在尽量少的 cache line 里面。
: 9 这些user space编程几乎不太可能考虑这个方面的东西。
: 例如 memory bank 根本管不着。
|
|
|
b*******s
发帖数: 5216 | 41 yup, it was just a 2 hours session.
up to "effective c++" standard, that's what we can expect
he is not in the industry
【在 T********i 的大作中提到】
: 说实话，真的没啥干货。
|
