本期内容


1. Tungsten内存分配内幕


2. Tungsten内存管理内幕




内存分配和管理内幕

恭喜Spark2.0发布，今天会看一下2.0的源码。

今天会讲下Tungsten内存分配和管理的内幕。Tungsten想要工作，要有数据源和数据结构，这时候会涉及到内存管理，而内存管理也是后续做很多分析和逻辑控制的基础。

内存分配

我们从内存分配的入口MemoryAllocator开始：

allocate() 分配的是一块连续干净的内存空间，如果不是干净的话，会先用zero方法，把里面填充为0。我们注意到操作的数据结构都是MemoryBlock。

MemoryBlock中pageNumber字段是public级别的，方便为TaskMemoryManager修改。内部有一个obj，onheap方式的话是一个字节数组，如果是offheap方式分配的是本地对象的指针。
其中会使用到一个Platform类，相当于Java Bean级别，提供对于数据一系列获取方法。

至于具体的内存分配是如何操作的，我们看一下具体的实现，首先是HeapMemoryAllocator，注释里说明可以分配16G原生数组。

从allocate里面看到，对于大数据量情况，会有一个Pool来管理，Pool中会预先存放各种尺寸的memory块，在获取时直接获取；小数据量的化经过字节对齐之后之后返回对象。

UnsafeMemoryAllocator中直接使用Platform的方法分配，这个方法没有实现，是通过jni，用C和C++实现的，其实就是用C语言分配个空间，跟new一个数组没有多大区别。

在申请内存时，如果不够的话会spill(溢出到磁盘)，之后看下release的内容，继续进行获取。

内存管理

无论是UNSAFE还是HEAP的方式，都是采用了MemoryBlock来分配，这有一个很大的好处，是让我们的内存使用者Task，能统一被内存的管理者TaskMemoryManager来分配.

TaskMemoryManager是如何来管理被task分配的内存呢，统一的方法是将地址编码成64字节的长整数。但是对于off-heap和on-heap编码方式是不同。

  • off-heap方式下，编码比较简单，直接将物理地址转成64位long即可。
  • 而在on-heap方式下，有一个很严重的问题，就是gc时候会导致内存发生改变。所以需要采用间接的方式来保存。实际管理时，我们会建立一个page table，其中会索引到实际的地址，而在编码长整数时，前13个字节代表page编号，指向page table中的某个page，而后51位则记录数据在page中的offset。
  • 很多page构成了page table，我们可以定位8192张page，大小是被java数组的上限来限制。理论上一个jvm能支持35TB。

我们看下TaskMemoryManager中的代码，pageTable是个MemoryBlock的数组，会使用一个BitSet来进行索引。

最后，我们有个问题，onheap模式下操作的时候，会根据offset来操作，有没有说操作多大的空间？
因为地址是64位的长整数，onheap方式获得逻辑地址时，会把起始offset和长度都编码进去，获取64位长整数时，有一套读取方式，虽然开始只知道offset，默认会知道下面有几位空间，也就是数据有多长。