https://gitlab.haskell.org/ghc/ghc/merge_requests/1701
Ömer
Ömer Sinan Ağacan , 10 Eyl 2019 Sal, 15:14
tarihinde şunu yazdı:
>
> It took 7 months to figure this one out. The compacting GC (which is enabled
> by
> default when heap residency is above 30%) needs two bits per closure: one for
>
It took 7 months to figure this one out. The compacting GC (which is enabled by
default when heap residency is above 30%) needs two bits per closure: one for
the actual "liveness" mark bit, another one for whether the object's new
location (computed during two scans in compacting GC) is in the
I don't think so, for two reasons:
- We update static thunks just fine so I don't think they're in a read-only
section.
- Forwarding pointers are needed when moving objects, and we don't move static
objects, so we don't need to make them forwarding pointers (I think you
confused forwarding
Just guessing here, maybe this thunk type lives in (read-only?) static
sections, and as such it will never be overwritten with forwarding
pointers?
Gabor
On 2/5/19, Ömer Sinan Ağacan wrote:
> I just came across a closure that is according to this code is not valid:
>
> >>> print
I'm relying on Simon M here. I'm out of my depth!
Simon
| -Original Message-
| From: ghc-devs On Behalf Of Ömer Sinan
| Agacan
| Sent: 05 February 2019 13:38
| To: ghc-devs
| Subject: Re: Min closure payload size?
|
| I just came across a closure that is according to this code
I just came across a closure that is according to this code is not valid:
>>> print *get_itbl(0x7b2870)
$8 = {
layout = {
payload = {
ptrs = 0,
nptrs = 0
},
bitmap = 0,
large_bitmap_offset = 0,
__pad_large_bitmap_offset =
Hi,
I was trying to understand why some info tables that have no ptrs and nptrs like
GCD_CAF end up with 1 nptrs in the generated info table and found this code in
Constants.h:
/*
-
Minimum closure sizes
