Search
Thursday, 13th of June 2019, 14:32:04 UTC
14:51:23
Bike
"Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS" well this is going to suck
15:01:46
drmeister
I have memory profiling in place - you can generate flame graphs for allocations.
15:02:37
drmeister
It's not as bullet proof as regular flame graphs - it may need a bit of tweaking to get it to work properly.
15:08:09
Bike
it ran out of memory allocating one of the intermediate forms for the programs
15:08:16
Bike
maybe i can tighten that up
15:09:25
drmeister
Yeah - that's a red flag. We should stay far away from any limits boehm has.
15:09:59
drmeister
We really should pull boehm into our build system - but dealing with autotools (brrrrr)
15:22:08
drmeister
No! Still not as of this morning. cracauer is working on it.
15:22:30
drmeister
We have troubles with things crashing and waf eating output.
15:22:55
drmeister
So not only are things broken but waf won't let us see what's broken. Grrrr
16:54:33
drmeister
How's the gfvm going?
16:59:33
Bike
i wrote something so that it should allocate less intermediate crap. i tried it and it crashed due to a silly mistake. now i'm building again.
17:03:39
kpoeck_
Regarding the Boehm message, shoudnât we set initially GC_INITIAL_HEAP_SIZE to a reasonable value? 10gb or 20gb?
17:04:43
Bike
i don't think 20 gigabytes is a reasonable amount of memory.
17:04:49
Bike
i know clasp is a hog, but honestly.
17:06:08
drmeister
I thought we got what we got.
17:06:39
kpoeck_
One can type export GC_INITIAL_HEAP_SIZE=10gb in the terminal
17:07:02
kpoeck_
And start clasp in the same terminal session
18:10:27
kpoeck
the environment variables to control the bdwgc are documented here: https://github.com/ivmai/bdwgc/blob/master/doc/README.environment
20:17:00
Bike
that might be entirely attributable to using funcall_consume_valist_, but i'm not sure
20:31:19
Bike
i have looked at funcall_consume_valist_'s code. maybe it actually is that bad.
20:32:04
Bike
can't we do that apply thing with the vla?
20:49:07
drmeister
An issue is that in some cases we don't know how many arguments are left in the register save area and how many are in the overflow area.
20:51:06
drmeister
There are four cases four X86_64 - 0, 1, 2, 3, 4
20:51:15
drmeister
Ha ha - off by one error.
20:51:19
drmeister
There are five cases.
20:53:03
drmeister
Then there is the number of arguments being passed.
20:55:18
Bike
well, recently it's been like half an hour, couple minutes more
20:55:52
Bike
this is where we have a vaslist and a function. there isn't a register save area, i don't think
20:56:23
drmeister
The vaslist points to a register save area.
20:56:45
drmeister
Could you drop by my office - I can explain what I think is going on here.
Friday, 14th of June 2019, 2:32:04 UTC