Я думал о том, как функциональные языки могут быть более привязаны непосредственно к их аппаратным средствам и задаются вопросом о каких-либо аппаратных реализациях сборки мусора.
Это значительно ускорит процесс, поскольку само аппаратное обеспечение неявно обрабатывает всю сборку, а не среду выполнения некоторой среды.
Это то, что делали машины LISP? Проводилось ли какое-либо дальнейшее исследование этой идеи? Является ли это слишком специфичным для домена?
Мысли? Возражения? Обсудить.
Из-за Generational Collection я должен сказать, что трассировка и копирование не являются огромными узкими местами для GC.
Что поможет, это аппаратные экраны READ, которые устраняют необходимость приостановки пауз в мире при выполнении сканирования стека и маркировки кучи.
Azul Systems сделала это: http://www.azulsystems.com/products/compute_appliance.htm Они представили на JavaOne презентацию о том, как их аппаратные модификации допускают полностью безотлагательный GC.
Еще одно усовершенствование - это аппаратные средства защиты от записи для отслеживания запоминаемых наборов.
Генерирующие GC, а тем более G1 или Garbage First, уменьшают количество кучи, которое они должны сканировать, только сканируя раздел и сохраняя список запоминаемых наборов для указателей перекрестных разделов.
Проблема заключается в том, что это означает, что в любое время мутатор (причудливое слово для "реальной программы" ) устанавливает указатель, который также должен помещать запись в соответствующий перегруженный набор. Таким образом, у вас есть (небольшие) накладные расходы, даже если вы не являетесь GCing. Если вы можете уменьшить это, вы сократите время паузы, необходимое для GCing, и общую производительность программы.
Да. Посмотрите на соответствующие разделы работы этих двух статей:
https://research.microsoft.com/en-us/um/people/simonpj/papers/parallel-gc/index.htm http://www.filpizlo.com/papers/pizlo-ismm2007-stopless.pdf
Или на этом:
http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon12StallFree.pdf
Одно из очевидных решений заключалось в том, чтобы иметь указатели на память, которые больше, чем доступная оперативная память, например 34-битные указатели на 32-битной машине. Или используйте самые верхние 8 бит 32-битного компьютера, если у вас всего 16 МБ ОЗУ (2 ^ 24). машины Oberon в ETH Zurich использовали такую схему с большим успехом, пока RAM не стала слишком дешевой. Это было около 1994 года, поэтому идея довольно старая.
Это дает вам пару бит, где вы можете сохранить состояние объекта (например, "это новый объект" и "я просто коснулся этого объекта" ). Когда вы делаете GC, предпочитаете объекты с "это новое" и избегайте "просто касания".
На самом деле это может показаться ренессансом, потому что ни у кого нет 2 ^ 64 байта ОЗУ (= 2 ^ 67 бит, во Вселенной около 10 ^ 80 ~ 2 ^ 240 атомов, поэтому возможно, что это невозможно много RAM когда-либо). Это означает, что вы можете использовать пару бит в сегодняшних машинах, если VM может сообщить ОС, как отображать память.
Была статья о лямбда-конце, описывающая, как вам нужен менеджер виртуальной памяти, поддерживающий GC, чтобы иметь действительно эффективный GC, и В настоящее время отображение VM выполняется в основном аппаратными средствами. Здесь вы:)
Ты студент-градир, звучит как хорошая тема для исследовательского гранта. Посмотрите на FPGA-дизайн и компьютерную архитектуру, есть много свободного процессорного дизайна, доступного на http://www.opencores.org/
Сбор мусора может быть реализован в качестве фоновой задачи, он уже предназначен для параллельной работы.
Пит
Я уверен, что некоторые прототипы должны существовать. Но разрабатывать и производить аппаратные функции очень дорого. Потребовалось очень много времени, чтобы реализовать MMU или TLB на аппаратном уровне, которые довольно легко реализовать.
GC слишком велик, чтобы эффективно внедряться в аппаратный уровень.
Старые спарковые системы имели помеченную память (33 бита), которая могла использоваться для маркировки адресов. Сегодня не установлено?
Это произошло из их наследия LISP IIRC.
Один из моих друзей построил GC поколения, который помечен, украв бит из примитивов. Он работал лучше.
Итак, да, это можно сделать, но nodody больше беспокоит тегирование.
ЗамечанияrunT1mes об GC, подготовленном с помощью аппаратного обеспечения, заслуживают внимания.
при достаточно большом массиве ворот (вершин-III), возможно, будет расширен расширенный MMU, поддерживающий действия GC.
Вероятно, наиболее важная часть данных, необходимая здесь, заключается в том, сколько времени (в процентах от времени процессора) в настоящее время расходуется на сбор мусора? Это может быть проблема.
Если мы идем после этого, мы должны учитывать, что аппаратное обеспечение обманывает память "за нашей спиной". Наверное, это будет "другой поток", на современном языке. Некоторая память может быть недоступна, если ее рассматривают (возможно, она разрешима с двухпортовой памятью), и, конечно, если HWGC собирается перемещать вещи вокруг, тогда ей придется блокировать другие процессы, чтобы они не мешали им, И делайте это так, чтобы вписываться в используемую архитектуру и язык (языки). Итак, да, это домен.
Посмотрите, что только что появилось... в другом сообщении... Глядя на журнал java GC.
Мне кажется, самая большая проблема - регистры процессора и стек. Одна из вещей, которые вы должны выполнить во время GC, - это перемещение всех указателей в вашей системе, что означает знание того, что это за указатели. Если один из этих указателей в настоящее время находится в регистре CPU, вам также нужно пройти его. Аналогично, если у вас есть указатель на стек. Таким образом, каждый кадр стека должен иметь какую-то карту, говорящую о том, что такое указатель, а что нет, и до того, как вы пройдете GC-переходы, вы должны получить любые указатели в памяти.
У вас также возникают проблемы с закрытием и продолжением, потому что внезапно ваш стек перестает быть простой структурой LIFO.
Очевидным способом является отсутствие указателей на стеке процессора или в регистрах. Вместо этого у вас есть каждый стек стека как объект, указывающий на его предшественника. Но это убивает производительность.
Почему это "ускоряет процесс"? Что именно должно делать оборудование? Он по-прежнему должен пересекать все ссылки между объектами, что означает, что он должен запускать большой кусок данных в основной памяти, что является основной причиной, по которой требуется время. Что бы вы получили от этого? Какая конкретная операция заключается в том, что вы считаете, что это можно сделать быстрее с поддержкой аппаратного обеспечения? Большая часть работы в сборщике мусора заключается только в указаниях/ссылках и иногда копировании живых объектов из одной кучи в другую. как это отличается от инструкций, которые ЦП уже поддерживает?
Сказав это, почему, по вашему мнению, нам нужна быстрая сборка мусора? Современный GC уже может быть очень быстрым и эффективным, вплоть до того, что он в основном решает проблему.