如何解决ghc的FUN_1_0,FUN_0_1等封闭类型是什么意思?
FUN_1_0
,THUNK_1_0
等封闭类型通常出现在堆配置文件中,但未在任何地方进行记录。 ghc-heap
中未记录的类型对应于these constants,Layout.hs
中还有一些线索,但尚不清楚这些含义是什么。
This answer建议FUN_1_0
和FUN_2_0
对应于一个或两个参数的函数,但这似乎是错误的(例如,因为没有FUN_3_0
)
各种FUN_
和THUNK_
类型是什么意思?
解决方法
变体FUN_m_n
和THUNK_m_n
只是FUN
和THUNK
的特例,旨在加快垃圾回收的速度。 (CONSTR_m_n
也有一组类似的CONSTR
特殊情况。)
FUN
堆对象是函数闭包。 THUNK
堆对象是表达式的暂停计算。两种类型的对象都可能包含 payload ,其中有几个单词大小的字段,它们给出函数主体或thunk表达式中所有自由变量的封闭值。 CONSTR
代表饱和的构造函数,其有效负载包括其字段的值。 Making a Fast Curry论文对此有一些有用的背景。
在任何这些闭包类型的有效负载中,其中一些字段可能是指针(指向装箱的值),而某些字段可能是非指针(未装箱的值直接出现在闭包中)。当垃圾收集器在堆上移动时,它需要跟随指针并忽略非指针。对于所有FUN
,THUNK
和CONSTR
(无论是特殊情况的_m_n
类型还是常规的),其信息表都有一个位图,用于指定其中有多少个字段有效负载以及哪些字段包含指针。但是,垃圾回收器需要重定向到信息表并处理位图,这是有代价的。
为加快垃圾收集速度,使用了不同的闭包类型定义了一些特殊情况,例如FUN_m_n
等,其中m
是指针字段的数量,而n
是指针字段的数量。非指针字段的数量。对于变量_0_1
,_1_0
,_2_0
和_0_2
,垃圾收集器可以立即确定字段总数和所有字段都是指针的事实(等等)。应该遵循)或非指针(因此应跳过),而不重定向到信息表位图。对于_1_1
变体,存在歧义,因为尚不清楚指针和非指针在有效负载中出现的顺序,因此已选择了先指针后非指针的顺序。如果闭包具有“非指针然后指针”,则它会退回到常规的FUN
或THUNK
位图方案。您可以在rts/sm/Scav.c
函数scavenge_block
中看到正在使用的算法,这是实际上对变体进行区别对待的少数几段代码之一。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。