freenode/#clasp - IRC Chatlog
Search
23:15:52
Bike
the answer appears to be nothing doing, at least without a lot of work that probably wouldn't be worth it right now
23:18:40
Bike
building up the system by loading fasls still entails some bootstrapping stuff, even if the compiler is run off line. though i should still be able to do some optimizations i wanted. i think.
23:20:49
drmeister
Hi frgo - I had a question for you. You defined a method void free() - does it need to have that name? I'm getting a weird warning about it.
23:22:00
frgo
hi drmeister: names are ... not that important. So, no, that method could be named differently.
23:34:28
Bike
maybe i can rearrange some things anyway. like i think we can probably define the basic classes pretty much right off
23:46:09
Bike
drmeister: unrelated question. (1) is my impression that we can't jit more than one thing at once in the near future correct? 2) does compile-file involve the jit other than for :compile-toplevel and load-time-value stuff?
23:46:30
Bike
unrelated questions, but then it sou nds like they're unrelated to each other, which is false... terrible.
1:44:49
whoman
was there a project, i forget the name, of shared CL code which clasp uses ? or something like this. i remember being linked to it from this channel but i cannot remember the name of the project
1:49:42
whoman
stassats, do you know if it is active or any plans about it ? on passing curiosity, i could contact the guy
1:58:00
whoman
i did not want to assume the file modification dates if anyone knew more. ah well ^_^
3:37:55
Bike
http://wingolog.org/archives/2014/01/19/elf-in-guile wingo can be informative even when they're not around
4:24:38
Bike
maybe we could do some junk to dump out elf with compiled functions in it, for dispatchers.
8:15:53
beach
The global allocator has two parts, namely a list of 2-word headers (or CONS cells) and a traditional heap as used by malloc() and free().
9:07:23
beach
Doug Lea's allocator also has some features that can be eliminated when used together with a garbage collector. In particular, caching of chunks, hoping that the same chunk will be allocated again soon, is of no use.
10:05:52
beach
This is getting interesting. Doug Lea's allocator is designed to handle arbitrary sequences of calls to malloc() and free(). I wonder how the design might change when used with a garbage collector. In such a context, there will be a large number of calls to malloc() with no calls to free(), followed by a large number of calls to free() with no calls to malloc().
10:18:47
Shinmera
I assume it's not a copying one then, though? Since with copying you don't really need to free anything.
10:19:59
beach
The per-thread GC is a sliding collector. Recently, I have become convinced that the global GC should be managed as combination of a mark-and-sweep collector for the headers and as a malloc/free heap for the racks.
10:20:25
beach
For example, ignoring caching, when there is a call to free(), the preceding and/or following chunk might be free. In that case, the chunk about to be freed must be coalesced with its neighbor(s) and those neighbor(s) must be unlinked from their respective free lists. But when there are several calls to free(), then one might be able to coalesce several adjacent blocks and only unlink at the end of the entire operation.