go二维map_mirrorlang——从0设计二维内存寻址语言及vm（五.内存管理的思考）

目录

鹏鹏李李：mirrorlang——从0设计二维内存寻址语言及vm 【目录】​zhuanlan.zhihu.com

由一段函数开始思考内存布局

func longestPalindrome(s string)(r string) {
    if(len(s)==0){
        return s
    }
	//第一遍，寻找对称点，复杂度为n
	history:=make(map[int]map[int]int)
	for i:=0;i<len(s)-1;i++{
		if(s[i]==s[i+1]){
			if(history[i]==nil){
				history[i]=make(map[int]int)
			}
			history[i][i+1]=2
		}
		if(i<len(s)-2&&s[i]==s[i+2]){
			if(history[i]==nil){
				history[i]=make(map[int]int)
			}
			history[i][i+2]=3
		}
	}

	//第二遍，扩展对称点,计算长度
	maxc:=0
	maxi,maxj:=0,0
	for i,jc:=range history{
		for j,c:=range jc{
			m:=i
			n:=j
			for m>0&&n<len(s)-1{
				m--
				n++
				if(s[m]==s[n]){
					c+=2
				}else {
					m++
					n--
					break
				}
			}
			delete(history[i],j)
			if(history[m]==nil){
				history[m]=make(map[int]int)
			}
			history[m][n]=c
			if(c>maxc){
				maxc=c
				maxi=m
				maxj=n
			}
		}

	}

	return s[maxi:maxj+1]
}

我这里有一个go语言函数代码，如果我用mirrorlang来在内存中布局这些函数，会出现什么问题呢？

1. history 这个map[int]map[int]int，这是一个可以无限扩容的局部变量；

mirrorlang如何为这样的局部变量分配空间？

回答：

对于数组类型，数组在内存中的排布，是x轴反向横向扩展的，由于代码是向下执行的，所以横向反而空间充足；

对于struct类型，结构是纵向布局的，也就是一个struct定义的成员数量是固定不变的；

所以golang map这个结构，是个

struct hmap{
cap
len
p* type
}

当我们定义一个map的时候，实际上会调用它的constructor函数，来进行内存初始化，也就是make()方法；

这个方法，并不是编译的时候计算的，而是运行的时候计算；对于golang，通过逃逸分析来判断map的实际内存分配是在堆还是在栈；

我们的内存，是二维的；

同样需要思考，这局部变量（分子）如果需要的纵向空间越来越大，该从哪给它分配内存的问题；

先总结一些我制定的的几个内存规则：

• 函数的执行流程，是自上而下的；
• 通常，已经被call的函数体，上下边界是不会发生变化的；
• 数组的元素增加，是自左向右排列
• struct是自上而下排列，固定成员个数

如果像map那样的struct里又有指针，指针指向的对象的空间分配，是我们需要计算的问题；

//例如，树这样的结构
type Node struct {
	Data []Node
	Value int
} 

它是可以无限递归套用自己；

如果一开始就给Data分配空间，它需要的纵向高度的公式为；

height()=1+height();这是无解的；

或者不给Data分配空间，而是把Data作为一个结构体指针 *struct，而这个height(Node)=2,这样也可以；Node的高度就是2，也就是一个int原子和一个point原子，水平长度是1；、

另一种方法是，我们把它改成

//例如，树这样的结构
type Node struct {
	Data []*Node
	Value int
} 

这样的话，Node的高度就是2，也就是一个int原子和一个point原子数组，水平长度是len(Data)；

如果是其他语言的程序员，他可能会想让内存更紧凑，这样可以更节省内存；

但我并不这么想，我想做一个漂亮、适合人观察的内存布局；就像写在作业本上写作业一样，你不可能把每个格子都写满，如果写满每个格子，老师会批评你是不是穷的买不起作业本。

实际上，我希望把这个分子，在内存中的布局，也绘制成一颗漂亮的树；这个也不难，可以通过计算坐标，让内存的布局更美丽；就像下图；

那么，还是那个问题；如何避免这种分子生长的过程中，出现内存碰撞？

方案1：

划分出堆内存；

提供malloc或者new函数，这些函数是标准库提供的，可以对这类分子生长的过程进行管理，预先划定一个矩形，如果超出矩形，则copy并重新申请一个更大的矩形，并复制过去；

我们还需要设计原子的双向指针，来保证互相连接的原子，当一个原子的坐标改变了内存坐标，能让连接它的原子感知到并及时修改；

我觉得这是一个可行的方案；

但缺点在于，函数体内的局部变量分子，被放置在函数体外部的堆中了；

方案2：

不划分堆区域；

依然是函数体矩形；

只是这个函数体的矩形，height和width都可以扩大；

定义分子的那一行，会随着分子生长，把分子下部的所有矩形向下推，从而开辟出生长空间；

被推向下的内存中的原子，依然需要双向指针，来保证改变了位置不会指针丢失；

这样做的好处，是不需要把整个内存空间，划分堆栈，维持函数体的完整性和独立性；

虽然这样的函数体具有完整性和独立性，但缺点也很明显；

当函数非常多，非常大的时候；需要下推的内存，会越来越大;这个问题要解决；