Здравствуйте, c-smile, Вы писали:
CS>Здравствуйте, D. Mon, Вы писали:
DM>>Ну вот окамловский сборщик компактифицирует и major heap периодически. И памяти ест мало по-умолчанию, как мы видим.
CS>Какая схема используется для компактификации? Как физически это происходит, т.е. сколько памяти надо на эту операцию?
Много подробностей тут не скажу. Там несколько проходов с раскраской блоков в 4 цвета, обращением указателей и пр.
First pass: encode all noninfix headers.
Second pass: invert pointers. Link infix headers in each block in an inverted list of inverted lists. Don't forget roots and weak pointers.
Third pass: reallocate virtually; revert pointers; decode headers. Rebuild infix headers.
Fourth pass: reallocate and move objects. Use the exact same allocation algorithm as pass 3.
Shrink the heap if needed.
Как я понимаю, объекты не переписываются в новую кучу, а двигаются внутри имеющейся ближе к началу.
ch = caml_heap_start;
while (ch != NULL){
word *p = (word *) ch;
chend = ch + Chunk_size (ch);
while ((char *) p < chend){
word q = *p;
if (Color_hd (q) == Caml_white){
size_t sz = Bhsize_hd (q);
char *newadr = compact_allocate (sz); Assert (newadr <= (char *)p);
memmove (newadr, p, sz);
p += Wsize_bsize (sz);
}else{
Assert (Color_hd (q) == Caml_blue);
p += Whsize_hd (q);
}
}
ch = Chunk_next (ch);
}
CS>Предлагаю объявить OCaml святым. Тогда можно в него просто верить. Т.е доказательства уже будут не нужны.
Можно конечно.
Но я тут еще и цифры приводил, можно не верить, а проверить.
Здравствуйте, Трурль, Вы писали:
Т>Только предварительно из окамла исключить ref Если в языке нет присваиваний указателей, то все ссылки направлены в одну сторону и можно копировать в ту же кучу.
Мутабельные указатели из major heap в minor отслеживаются отдельно, про них помнит специальный список.
http://rwmj.wordpress.com/2009/08/08/ocaml-internals-part-5-garbage-collection/
Здравствуйте, D. Mon, Вы писали:
DM>Оно и без изменения настроек GC приемлемое. Т.е. оверхеда 30-50% обычно вполне достаточно, и даже для обгона Си 100% не потребовалось.
Написал как-то утилитку работающую с деревом грубо структурой файловой системы в памяти, в общем понадобилось переписать на C++,
(с исходниками хотели) решил быстренько переписать (C++ + stl + boost), памяти стало кушать в два раза больше
Конечно это не показатель, но OCaml память на самом деле кушает очень экономно.
Здравствуйте, FR, Вы писали:
FR>Здравствуйте, D. Mon, Вы писали:
DM>>Оно и без изменения настроек GC приемлемое. Т.е. оверхеда 30-50% обычно вполне достаточно, и даже для обгона Си 100% не потребовалось.
FR>Написал как-то утилитку работающую с деревом грубо структурой файловой системы в памяти, в общем понадобилось переписать на C++,
FR>(с исходниками хотели) решил быстренько переписать (C++ + stl + boost), памяти стало кушать в два раза больше
FR>Конечно это не показатель, но OCaml память на самом деле кушает очень экономно.
Не скажу как в boost, но в stl частенько получается оверхед на временных объектах — move semantics есть только в новом стандарте. Что удивительно, иммутабельных или COW строк даже в бусте в стандартной поставке нет.
