Аппаратные средства помогли сборке "мусора"

Да. Посмотрите на связанные разделы работы этих 2 бумаг:

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 использовали такую ​​схему с большим успехом, пока оперативная память не стала слишком дешевой. Это было примерно в 1994 году, поэтому идея довольно старая.

Это дает вам пару битов, в которых вы можете сохранить состояние объекта (например, «это новый объект» и «я только что коснулся этого объекта»). При выполнении GC предпочитайте объекты с надписью «это новое» и избегайте «только что коснулись».

На самом деле это может увидеть ренессанс, потому что ни у кого нет 2 ^ 64 байт оперативной памяти (= 2 ^ 67 битов; во вселенной около 10 ^ 80 ~ 2 ^ 240 атомов, так что это может быть невозможно много оперативной памяти когда-либо ). Это означает, что вы можете использовать пару бит в современных машинах , если виртуальная машина может указать ОС, как отобразить память.

Был статья о лямбде окончательное описание, как Вам нужен осведомленный о GC диспетчер виртуальной памяти, чтобы иметь действительно эффективный GC, и отображение VM сделано главным образом аппаратными средствами в эти дни. Вот, пожалуйста :)

Вы аспирант, звучит как хорошая тема для исследовательского гранта для меня. Посмотрите на дизайн FPGA и компьютерную архитектуру. Существует множество бесплатных проектов процессоров, доступных на http://www.opencores.org/

Сборка мусора может быть реализована как фоновая задача, она уже предназначен для параллельной работы.

Пит

Я почти уверен, что некоторые прототипы должны существовать. Но разрабатывать и производить аппаратные особенности очень дорого. Потребовалось очень много времени, чтобы реализовать MMU или TLB на аппаратном уровне, что довольно легко реализовать.

GC слишком велик, чтобы его можно было эффективно внедрить в аппаратный уровень.

В старых системах sparc была помечена память (33 бита), которую можно было использовать для маркировки адресов. Не подходит сегодня?

Это пришло из их наследия LISP IIRC.

Один из моих друзей создал GC поколения, который помечал, как будто немного крал у примитивов. Это сработало лучше.

Итак, да, это может быть сделано, но никто больше не мешает помечать вещи.

Комментарии runT1mes о GC с аппаратной поддержкой поколений стоит прочитать.

, учитывая достаточно большой массив гейтов (на ум приходит вершина-III), возможен расширенный MMU, который поддерживает действия GC.

Несколько великих умов в Массачусетском технологическом институте еще в 80-х годах создали чип SCHEME-79 , который непосредственно интерпретировал диалект схемы, был разработан с использованием LISP DSL, и имели аппаратный gc встроенный.

Почему был бы он "ускорять вещи"? Что точно должны делать аппаратные средства? Это все еще должно пересечь все ссылки между объектами, что означает, что это должно пробежать большой блок данных в оперативной памяти, которая является главной причиной, почему это занимает время. Что Вы получили бы этим? То, какая конкретная операция - это, что Вы думаете, могло быть сделано быстрее с поддержкой оборудования? Большая часть работы в сборщике "мусора" просто следует за указателями/ссылками и иногда копирует живые объекты от одной "кучи" до другого. как это отличается от инструкций, которые уже поддерживает ЦП?

После этих слов почему Вы думаете мы потребность более быстрая сборка "мусора"? Современный GC может уже быть очень быстрым и эффективным, до такой степени, когда это - в основном решенная проблема.

Я заключаю, что самой большой проблемой являются регистры ЦП и стек. Одной из вещей, которые необходимо сделать во время GC, является пересечение все указатели в системе, что означает знать, каковы те указатели. Если один из тех указателей находится в настоящее время в регистре ЦП затем, необходимо пересечь это также. Так же, если у Вас есть указатель на стеке. Таким образом, каждый стековый фрейм должен иметь своего рода карту, говорящую, что является указателем и что не, и прежде чем Вы сделаете любой GC, пересекающий Вас, должен вывести любые указатели в память.

Вы также сталкиваетесь с проблемами с закрытиями и продолжениями, потому что внезапно Ваш стек прекращает быть простой структурой LIFO.

очевидный путь никогда не состоит в том, чтобы содержать указатели на стеке CPU или в регистрах. Вместо этого у Вас есть каждый стековый фрейм как объект, указывающий на его предшественника. Но это уничтожает производительность.

Вероятно, наиболее важная часть данных, необходимых здесь, это то, сколько времени (в процентах от процессорного времени) в настоящее время тратится на сборку мусора? Это может быть не проблема.

Если мы пойдем после этого, мы должны учитывать, что аппаратное обеспечение дурачится с памятью «за нашей спиной». Я думаю, что это будет "другая нить", на современном языке. Некоторая память может быть недоступна, если ее исследуют (может быть, она решается с помощью двухпортовой памяти), и, конечно, если HWGC собирается что-то перемещать, то ему придется блокировать другие процессы, чтобы они не мешали им. , И делайте это так, чтобы соответствовать архитектуре и используемому языку (языкам). Так что, да, для конкретного домена.

Посмотрите, что только что появилось ... в другом посте ... Глядя на журнал GC Java.