Search
Thursday, 13th of June 2019, 12:10:27 UTC
12:11:35
drmeister
https://www.irccloud.com/pastebin/45baWkxu/
12:12:20
drmeister
It's not the first time this GF was invoked. It appears to be reproducible.
12:13:41
drmeister
I added more logging information. Where you generate the program try putting in some validation to catch where bad opcodes are entering.
12:14:06
drmeister
We can run with this high level of logging - it doesn't slow the build down by much.
12:14:09
Bike
well in this case it looks like the "opcode" is the closure
12:14:19
Bike
either that or out of bounds
12:14:56
Bike
actually this is just invalid
12:15:03
Bike
the eql shouldn't be there
12:15:18
Bike
because... i see the problem
12:15:39
drmeister
Ah - right - I wasn't thinking about it yet.
12:15:44
drmeister
The opcode is the EQL
12:16:07
drmeister
It's interpreting the EQL at ip=1 as an opcode.
12:16:08
Bike
which is because in the opcode map *isa* in dtree.lsp, i have eql-search instaed of eql.
12:17:11
Bike
so it doesn't get "linked" correctly.
12:17:20
Bike
have you pushed your changes? i can fix it and make it a bit more robust to that
12:17:53
drmeister
Yes - I pushed everything. It's just adding more logging statements.
12:20:11
drmeister
I like the virtual machine idea. Let's get it working and compiling.
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, 0:10:27 UTC