Design: Помеченные указатели GC

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

@sebmarkbage у вас есть план для предложения enum?

Для тега: вы бы предпочли, чтобы виртуальная машина предоставила вам свойство «Доступно N бит тега» и все, что выше, вы обрабатываете самостоятельно, или автоматически магически использовать побочное хранилище, если вы превысите неопределенный лимит?

@sebmarkbage , мы думаем о возможности (хотя вы, вероятно, в первую очередь имеете в виду не тегированные указатели, а теги в заголовках объектов, а также тегированные целые числа для простых перечислений). Однако это будет довольно сложно из-за разнообразия виртуальных машин и архитектур и, по сути, потребует создания примитивов как сумм, так и продуктов в системе типов Wasm. Пока трудно сказать, удастся ли это сработать.

@jfbastien Я еще не уверен, лучше ли было бы управлять им или

Кажется, я не могу найти предложение enum в Интернете. Это было частью типов значений, но я думаю, что мы можем сделать это независимо от типов значений. cc @littledan

@ rossberg-chromium Я имел в виду тегированные указатели, но теперь, когда вы это упомянули, я вижу, как теги в заголовках объектов могут быть более полезными в некоторых проектах, таких как V8. Я видел, что полезно выбрать один или другой в зависимости от платформы. Действительно сложно.

@ rossberg-chromium Не могли бы вы быть более конкретными, когда вы будете использовать термин «мы» как «мы думаем о» в будущем. Насколько мне известно, эта группа сообщества не обсуждала никаких мыслей по этому поводу, и я не хочу, чтобы работа этой группы сообщества была искажена. Например, вы можете в будущем называть это «Команда v8» или создать имя для подгруппы, дающей членство. Если председатели позволили продолжиться частным беседам, которые определяли направление работы этой группы, не держа членов в курсе и не контролируя их, то не могли бы они вернуть своего председателя. Если есть председатели, не избранные членами, не могли бы они вернуть свои кресла.

Я бы предложил использовать тегированные указатели таким образом, чтобы они не зависели от типов значений или типизированных объектов. Например, вы можете захотеть ограничить здесь 2-4 битами тега, тогда как ADT, добавленный в JavaScript, не должен вызывать такое ограничение. cc @tschneidereit

Когда @ rossberg-chromium говорит о «мы», он имеет в виду неформальную обстановку среди людей, работающих над WASM. Учитывая, что я сижу в трех метрах от него, создание определенной подгруппы, которая улучшит это общение, кажется огромным трудом :-)

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

@titzer По совпадению, «мы» (@ lars-t-hansen, я и некоторые другие люди из wasm) обсуждали ту же основную идею некоторой ограниченной суммы, которая всегда допускала представление помеченных слов.

Этим летом из разговора выпала идея о том, что в проекте, где есть отдельная куча объектов, поддерживающих gc (возможно, TypedObjects), могут быть два новых типа wasm:

«Указатель» - это непрозрачная ссылка (возможно, пустая) на некоторую вещь gc'd в куче с поддержкой gc. Это 4 байта на Wasm-32 и 8 байтов на Wasm-64.

«Коробка» - это тройка размером с указатель:

• бит указателя указателя (1 бит)
• биты тегов (2 или 3 бита, могут зависеть от размера слова)
• значение (указатель, если указатель указателя установлен, в противном случае - целое число)

Некоторые правдоподобные операции:
boxptr (указатель, тег) -> Box [1, тег, указатель]
boxval (целое число, тег) -> Поле [0, тег, целое число & ~ 15]
ptrbitof (Коробка) -> 0 или 1
tagof (Коробка) -> тег
ptrof (Box) -> Указатель или ноль, если поле не является блоком указателя
valof (Box) -> целочисленное значение или 0, если поле не является целочисленным.

Локальные и глобальные переменные в wasm будут иметь прямоугольный или ptr-типизированный тип в дополнение к текущим типам. Указатели и блоки не хранятся в линейной куче.

То, что я набросал, должно подходить и работать, по крайней мере, для многих динамических языков; на практике 3 бита тега (бит указателя плюс два бита) обычно в порядке, дополнительные биты тега могут быть сохранены в объектах после этого. Биты указателя и тега хранятся в младшем бите слова.

Также было бы неплохо разрешить переинтерпретировать целочисленный блок как целочисленное значение, это недопустимо, если реализация wasm может доказать, что блок является целочисленным блоком, и то же самое, чтобы разрешить целочисленное преобразование в целое число. box реализацией wasm, просто маскируя бит указателя. Это, вероятно, требует определения того, какой бит является битом указателя. В любом случае, это обеспечивает биты размера слова-1 для целых чисел, «тег» - это просто битовое поле в большем значении.

@ lars-t-hansen Я думаю, что необходимы операторы проверки типов, чтобы код мог поднять if(is_int(p)) ... а затем компилятор знал бы, что p помечено как целое число, а не указатель, и мог оптимизировать valof() без необходимости выполнения компилятором подъема. Я не вижу необходимости в ptrof() поскольку среда выполнения в любом случае должна проверять тип при использовании, а целое число - это просто еще один тип для тестирования.

Не уверен в том, что теги называются «боксом», так как «бокс» часто означает выделение в блоке кучи.

Существует возможность также проверить или замаскировать биты старшего адреса, в то же время, когда маскируются младшие биты тега, что доказывает, что индекс находится в линейной куче. Я боролся за признание этого в течение двух лет, это требует большего внимания к улучшениям вывода типов, которые в настоящее время являются P5 в коде Mozilla, не могли бы вы подумать об этом, пожалуйста.

@wllang , да, я придумал это в своей голове, в частности, будут ли какие-либо гарантии производительности, связанные с такими тестами. is_int (x) эквивалентен eqz (ptrbitof (x)), который, во-первых, не так уж сложно распознать; is_ptr (x) - это просто ptrbitof (x). Поскольку это стековая машина, действительно существует тонкая грань между гипотетической однобайтовой операцией «i32.isint» и двухбайтовой операцией, состоящей из двух унарных однобайтовых операций, «i32.ptrbit; i32.eqz».

Но не имеет значения точная форма, важен эффект. Кажется очевидным, что в пределах "if (is_ptr (x)) {...} else {...}" компилятор может предположить, что x является указателем в блоке then и целым числом в блоке else, если он может подтвердить значение эквивалентность x в этих блоках x в тесте. Это не кажется сложным для системы на основе SSA. Но вы бы потребовать пропуск проверки тега в пределах этих блоков?

Предположим, мы позволяем байт-коду давать два значения; злоупотребляя синтаксисом, операция ptr_i32.ptrof вернет указатель (или ноль) и логическое значение. Тогда не было бы никаких вопросов о том, что компилятор должен «знать», у него просто было бы значение, которое по конструкции является указателем. (Есть также вопрос о системе типов для этих типизированных объектов и о том, в каком смысле типизируются указатели, но я думаю, что это, вероятно, ортогонально тегированию.)

(Слегка отвлекаясь, есть дополнительные интересные идеи о том, следует ли разрешать арифметические и побитовые операции для блоков с возможно-int с определенными простыми тегами, с возвратом какого-либо кода состояния, сравнимыми с тегами добавления в SPARC. I32x2.add k, a, b приведет к (a + b, 0), если и a, и b являются блоками int с младшими битами тега k == 0 и нет переполнения, в противном случае (мусор, 1). i32x2.or k, a, b То же самое: a | b. Эти операции сложно эффективно выразить на уровне wasm, но их легко реализовать на уровне оборудования. Но возможно, что они слишком специализированы, чтобы того стоить - необходимо указать, что это интересно Lispish языков в wasm.)

Что касается старших битов адреса ... Я не знаю, что вы писали об этом раньше. Вы хотите реализовать какой-либо тип схемы BiBoP или хотите использовать старшие биты для тегов?

(Отсылка к упомянутой вами ошибке Mozilla?)

необходимо сделать так, чтобы лиспишские языки были ориентированы на wasm.

Если вы думаете, что WebAssembly не должен пытаться эффективно поддерживать все языки программирования, я думаю, вы недооцениваете важность Wasm. Если все сделано правильно, Wasm захватит мир. Wasm уменьшит блокировку операционных систем, архитектур ЦП и (я надеюсь) языков программирования. Все будут использовать его как для автономных, так и для онлайн-приложений, а также для клиентов и серверов.

Этот мир не должен быть миром, в котором определенные методы программирования и языки программирования обречены на то, чтобы быть неэффективными и непрактичными, потому что дизайнеры WebAssembly считали, что эти языки недостаточно «важны» для поддержки. Многие вещи, которые мы сейчас принимаем как должное, а также особенности новых языков, зародились в малоизвестных академических языках и / или Лиспе.

Наша цель должна заключаться в том, чтобы поддерживать все языки и все методы программирования с приличной производительностью, скажем, всегда в пределах 2-кратного объема памяти и процессорного времени по сравнению с оптимальной реализацией данного метода. Во-первых, высокопроизводительная реализация Wasm должна иметь возможность эффективно размещать другую высокопроизводительную реализацию Wasm или JVM или CLR, работающие внутри нее (все из которых будут использовать внешний механизм Wasm для генерации кода), или виртуальную машину Lisp или Безстековый Python. Помимо всего, что подразумевается, я хотел бы видеть продолжения (или, по крайней мере, какую-то систему микропотоков), «первоклассные» метки для быстрых переходов внутри функции ... ну, в основном все в Future Features, а затем и некоторые. Хотя работа должна быть приоритетной, давайте не будем забывать, что все это важно.

@ lars-t-hansen Мне бы хотелось лучше понять ваши дизайнерские идеи для GC / непрозрачной кучи (а также идеи всех остальных). Какое влияние окажут биты тега на виртуальную машину WebAssembly?

Как сделать виртуальную машину «универсального назначения»? что-то, что

• Поддерживает точный компактный сборщик мусора поколения
• Поддерживает срезы массива и указатели, которые относятся к середине объекта или массива, а не только к началу
• Поддерживает объектные системы, основанные как на «тонких», так и на «толстых» указателях - или на обоих! (тонкие указатели полагаются на информацию о типе, хранящуюся в указанном объекте, в то время как жирные указатели хранят эту информацию в одном или двух дополнительных словах рядом с указателем)
• Разрешает "возможно указатели", которые могут динамически переключаться между указателями и целыми числами.
• Эффективно поддерживает типы объединения (указатель на A, B или C - он должен быть одним из них, но какой из них является динамическим)
• Насколько это возможно в рамках наших ограничений безопасности, позволяет клиенту контролировать выделение памяти и сборщик мусора.
• Поддерживает непрозрачные ссылки - даже если это, похоже, противоречит общей цели - поставить клиентский код Wasm на «место водителя», например, позволить клиенту выполнять свои собственные алгоритмы сборки мусора.
• Поддерживает другие вещи, о которых я даже не думал

Отказ от ответственности в том, что этот комментарий не относится к проблеме в OP.

Если вы думаете, что WebAssembly не должен пытаться эффективно поддерживать все языки программирования, я думаю, вы недооцениваете важность Wasm. Все сделано правильно, Wasm захватит мир ...

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

Я лично не думаю, что у WebAssembly нет средств для реализации такого грандиозного разнообразия приложений; Я лично заинтересовался WASM с точки зрения концепций виртуальных интернет-приложений, не ориентированных на браузер, которыми можно безопасно делиться и пользоваться, как html и css, без прикрепления к документу, публикующему реальность просмотра веб-страниц. В частности, я не думаю, что основные обязательства WebAssembly полностью исключают его из обсуждения, которое продвигает возможность ISA, выполняющего все эти виды возможностей, независимо от того, будет ли этот ISA WebAssembly для вашей данной проблемной области.

Я не думаю, что "захватить мир" - отличная цель для стрельбы

Просто мое предсказание. Я не говорю, что целью является захват мира - я говорю, что WebAssembly занимает уникальное положение, так что есть хороший шанс, что он захватит мир, и никто специально не пытается этого добиться.

Итак, каково влияние битов тега на виртуальную машину WebAssembly? Для чего они?

Я извлек свои комментарии сверху и немного уточнил, чтобы у нас было место, где мы можем наблюдать за развитием идей, без необходимости каждый раз сканировать всю эту цепочку:
https://github.com/lars-t-hansen/moz-sandbox/blob/master/wasm-tagging.md

В этой рецензии также есть немного больше оснований для «зачем помечать теги?». и некоторые комментарии по безопасности, известному уровню техники и т. д.

@qwertie , я не хочу мешать Wasm или мешать ему поддерживать какой-либо конкретный язык. Но мы, вероятно, должны признать, что некоторые исходные языки более важны, чем другие в контексте WebAssembly, а также что хорошая поддержка некоторых языков потребует больших усилий. Для Scheme нам понадобятся замыкания, хвостовые вызовы, первоклассные продолжения, динамически типизированные объектные поля, динамически типизированные переменные и эффективная общая арифметика. Некоторые из них могут быть реализованы из более простых конструкций по приемлемой цене. Хвостовые вызовы и продолжения можно смоделировать, поместив все кадры в кучу gc'd и / или в стек, управляемый вручную, но вы, вероятно, этого не хотите, это, вероятно, слишком дорого. Так что вам понадобится встроенная поддержка. Но если Scheme - единственный вариант использования call / cc, я думаю, будет нелегкая битва за то, чтобы его приняли; В конце концов, схема - это мертвый язык.

Обсуждение тегов довольно увлекательно, потому что до сих пор дискуссии на нашей стороне забора касались того, чтобы взять то, что у нас должно быть (указатели в непрозрачную кучу), и добавить дешевую функцию, которую многие считают полезной, хорошо работающей и переносимой ( теги с младшими битами), что затем открывает еще одну идею (хранение данных, не являющихся указателями, в части указателя тегированного объекта). Это имеет большое значение для поддержки Lisp, Prolog и некоторых других языков.

@sebmarkbage действительно спрашивал о более общей схеме тегов, и пространство для дизайна довольно велико, но ИМО, мы должны руководствоваться вариантами использования, и варианты использования, вероятно, являются конкретными методами реализации, которые доказали свою ценность, для языков, которые достаточно широко распространены. используется для «материи». (А для языков, которые не поддерживаются этой стратегией, всегда есть плоская память и собственный сборщик мусора, если вы хотите, чтобы эти языки работали в Интернете.)

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

Я не согласен с тем, что указатели на непрозрачную кучу - это функция, которая должна быть у WebAssembly. Я могу придумать три возможных направления поддержки WebAssembly для динамических языков и языков с GC:

1. Только беспокойтесь о том, чтобы быть хорошей виртуальной машиной для статических языков без GC.
2. Откройте кучу JS-совместимого типизированного файла и кучи со сборкой мусора.
3. Предоставьте примитивы, необходимые для реализации динамически типизированных языков (или статически типизированных языков с GC) в WebAssembly: например, исправление кода JIT, обход стека для линейной памяти со сборкой мусора и т. Д.

MVP ограничил свою область действия 1-м направлением, не прибегая к нему после MVP.

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

Однако я считаю, что 3-е направление - лучшее долгосрочное направление для WebAssembly. Второе направление, по-видимому, мотивировано упрощением работы с DOM браузера из WebAssembly. Однако никто не будет писать код непосредственно в WebAssembly, поэтому потребуется некоторая языковая поддержка, которая могла бы использовать процедурный JS API для доступа к DOM так же эффективно, как если бы был низкоуровневый доступ к DOM.

Второе направление также позволит бэкэндам WASM для JVM / .net, или Scheme, или Ruby повторно использовать сборщик мусора JavaScript. Однако сборщики мусора не универсальны: вероятный результат, похоже, вводит постоянное требование к виртуальным машинам WASM включать типизированную + кучу с сборкой мусора, которая не будет удовлетворять требованиям производительности многих приложений.

Третье направление требует большей работы, но в долгосрочной перспективе должно позволить и более простые автономные виртуальные машины WASM, и снизить сложность виртуальных машин браузера, поскольку все больше сегодняшних героических усилий по оптимизации переносятся с виртуальных машин JavaScript в изолированную программную среду WASM.

Ранее я создал # 733, чтобы обсудить относительный приоритет предоставления кучи JavaScript GC WebAssembly по сравнению с открытием примитивов для реализации сборщика мусора. Возможно, дальнейшее обсуждение направления WASM GC может продолжиться там, и этот вопрос может оставаться сосредоточенным на тегированных указателях GC с предположением, что в WASM будет добавлена ​​поддержка для непрозрачных указателей на кучу GC.

@ lars-t-hansen в вашей записи не упоминается, как это связано со сборкой мусора или с идеей области памяти для непрозрачных ссылок. Есть ли базовое предположение, что непрозрачная ссылка «куча» или «таблица» будет простым массивом «ящиков» (или эээ ... «помеченных Ptrs» ... TP?), Так что любой из этих ящиков может ссылаться на объект JS, который, таким образом, будет поддерживаться JS GC?

После просмотра документа мне пришло в голову, что, возможно, ваша идея состоит не в том, чтобы WebAssembly выполнял сборку мусора на стороне Wasm, а в том, чтобы позволить непрозрачной области ссылок содержать обе ссылки на объекты JS (чтобы предотвратить их сбор) и другие вещи, такие как целые числа и внутренние ссылки на себя. Затем для WebAssembly может быть создан (ненадежный) сборщик мусора, который поддерживает непрозрачную справочную область.

Становится теплее?

О первоклассных продолжениях - это единственная функция, которая, я не уверен, нам нужна. Конечно, сопрограммы или легкие стеки, но продолжения? Кто-нибудь на самом деле использует их для чего-то другого, кроме как для создания каких-то волокон / сопрограмм / нитей, которые ведут себя как набор стеков? Может быть, этого достаточно, чтобы поддерживать какую-то «легковесную» штуку с стеком с кодом операции коммутатора. В этом случае call/cc не будет доступен в WebAssembly, но то, что люди обычно создают из call/cc , будет.

Я согласен с @AndrewScheidecker в том, что акцент на демонстрации примитивов обеспечит гибкость, позволяющую всем языкам программирования, текущим и будущим, ориентироваться на WebAssembly и эффективно запускать код (и использовать разные сборщики мусора для разных рабочих нагрузок). С другой стороны:

• Я глубоко забочусь об интероперабельности; наличие встроенного сборщика мусора может упростить взаимодействие различных языков, использующих сборщик мусора.
• Сборщики мусора могут быть большими частями программного обеспечения, и необходимость загрузки разных сборщиков мусора с каждого веб-сайта может быть обременительной.

Итак, я думаю, мне бы хотелось, чтобы был какой-то сборщик мусора по умолчанию, но реализация собственного сборщика мусора в Wasm не должна иметь больших недостатков по сравнению с использованием сборщика мусора по умолчанию.

@AndrewScheidecker , честно - это не факт, что у нас должны быть непрозрачные указатели в куче gc'd. Я предлагаю продолжить это обсуждение в Выпуске № 733, как вы предлагаете. Попутно, однако, я считаю, что ваше утверждение о том, что «Третье направление [...] в долгосрочной перспективе должно позволить и более простые автономные виртуальные машины WASM, и уменьшить сложность виртуальных машин браузера, поскольку все больше сегодняшних героических усилий по оптимизации переносятся с виртуальных машин JavaScript. в песочницу WASM ". для его поддержки нужны и аргументы, и код; далеко не очевидно, что это правда.

@qwertie , я предполагаю, что будут локальные переменные wasm и, возможно, глобальные переменные типа Ptr и Box; что непрозрачные объекты могут иметь поля, которые будут статически типизированы как Ptr или Box; и что сборщик мусора системы будет отслеживать эти поля, имея точную достоверную информацию об их содержимом. Идея заключалась - здесь - не в поддержке какого-либо типа подключаемого сборщика мусора, который я считаю проектом другого типа. (Опять же, это обсуждение началось как «можем ли мы добавить теги к непрозрачным указателям?».)

В среду, 4 января 2017 г., в 14:59, Эндрю Шайдекер < [email protected]

написал:

Обсуждение тегов довольно увлекательно, потому что до сих пор
обсуждение на нашей стороне забора было о том, чтобы взять то, что мы должны
есть (указатели на непрозрачную кучу) и добавление дешевой функции

Я не согласен с тем, что указатели на непрозрачную кучу - это функция, которую WebAssembly
должен иметь. Я могу придумать три возможных направления для WebAssembly's
поддержка динамических языков и языков с GC:

1. Только беспокойтесь о том, чтобы быть хорошей виртуальной машиной для статических языков без GC.
2. Откройте кучу JS-совместимого типизированного файла и кучи со сборкой мусора.
3. Раскройте примитивы, необходимые для реализации динамически типизированных
   языки (или статически типизированные языки с GC) в WebAssembly: например, JIT
   исправление кода, обход стека для сбора мусора в линейной памяти и т. д.

MVP ограничил свою область действия 1-м направлением, не взяв на себя обязательство
это пост-MVP.

Да, и это было сделано намеренно, чтобы предотвратить расползание функций и обеспечить
успех.

В различных контекстах то, что мы обсуждали, является управляемыми данными как _extension_
в WebAssembly (я даже считаю, что название Managed Data Extensions, или MDX,
быть хорошим кандидатом). Расширение управляемых данных позволит использовать код WASM.
для выделения низкоуровневых структур отдельно от линейной памяти, которые
управляемый (то есть GC'd) механизмом WASM. Структуры будут набраны, чтобы разрешить
распакованные поля и будут достаточно низкоуровневыми, чтобы позволить реализовать
объектная модель языков более высокого уровня, таких как Java (с vtables, class
указатели и т. д.), Go, функциональные языки и т. д.

Позиционирование управляемых типов данных, значений и операторов как расширения
позволит иметь базовую реализацию WASM, которая просто выполняет
не поддерживает расширение. В таких реализациях было бы возможно
(хотя это потребует некоторой работы), чтобы реализовать автоматический перевод, использующий
часть линейной памяти (или отдельная линейная память) для имитации этих
структуры и реализовать сборщик мусора, хотя и с низкой производительностью.

Эта проблема и страница дизайна сборщика мусора http://GC.md предполагают второе
направление. В контексте этого предположения предоставление битов тегов для GC
указатели действительно имеют смысл как дешевое расширение непрозрачных указателей сборщика мусора.
это «надо» поддерживать.

Однако я считаю, что 3-е направление - лучшее долгосрочное направление для
WebAssembly. Второе направление, кажется, мотивировано тем, что
работать с DOM браузера из WebAssembly. Однако писать никто не будет
код прямо в WebAssembly, поэтому потребуется некоторая языковая поддержка,
и это может использовать процедурный JS API для доступа к DOM так же, как
эффективно, как если бы был низкоуровневый доступ к DOM.

Второе направление также позволит использовать бэкенды WASM для JVM / .net или Scheme,
или Ruby для повторного использования сборщика мусора JavaScript. Однако фигня
коллекционеры не универсальны: вероятный результат
введение постоянного требования для виртуальных машин WASM включать типизированный + GCed
куча, которая не удовлетворяет требованиям производительности многих приложений.

Третье направление требует большей работы, но в долгосрочной перспективе оба
позволяют упростить автономные виртуальные машины WASM и упростить виртуальные машины в браузере
поскольку все больше сегодняшних героических усилий по оптимизации переносятся с виртуальных машин JavaScript
в песочницу WASM.

Я ранее создал # 733
https://github.com/WebAssembly/design/issues/733, чтобы обсудить
относительный приоритет предоставления кучи JavaScript GC WebAssembly vs
демонстрация примитивов для реализации сборщика мусора. Возможно, дальше
обсуждение направления WASM GC можно продолжить там, и этот вопрос
может оставаться сосредоточенным на помеченных указателях сборщика мусора с предположением, что поддерживает
будет добавлен в WASM для непрозрачных указателей на кучу сборщика мусора.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/WebAssembly/design/issues/919#issuecomment-270484689 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/ALnq1EpdSRskLiuHx4v5M83T4IS9wmx1ks5rPAgggaJpZM4LPxE5
.

@ lars-t-hansen, ясно, что явная пометка / снятие тегов необходима для целых чисел, но каков вариант использования для различения упакованных и распакованных ссылочных типов в системе типов? Есть ли какая-либо операция с неупакованной ссылкой, которая не может быть предоставлена ​​напрямую для упакованной ссылки? В этом случае вам не нужно вводить первое.

@titzer Re: «эмулировать эти структуры и реализовать

Какова природа этих «недостатков производительности»?

Моя интерпретация из моего опыта в этих связанных проектах заключается в том, что поставщики веб-браузеров являются частью проблемы или что достижение соглашения является невероятной проблемой, и, таким образом, сообществу нужно, чтобы производители веб-браузеров обеспечивали низкоуровневую высокую производительность. язык, так что разработка может быть свободна от требования соглашения между поставщиками веб-браузеров. Поэтому я призываю продолжать сосредоточиваться на этой цели на благо веб-сообщества, и что управляемые объекты отвлекают от этой цели.

Я бы просто удалил управляемые объекты более высокого уровня и управляемый сборщик мусора из wasm, удалил его из будущих функций, сосредоточился на ядре и попросил группы, имеющие проблемы с производительностью с их объектными системами и реализациями сборщика мусора в линейной памяти, сообщить о них, чтобы они могли быть рассматривается в основной задаче проектирования.

Мы уже знаем некоторые проблемы, связанные с тегированными точками в линейной памяти, и пути их решения - улучшенный вывод целочисленных типов, который я пробовал, но пока не смог достичь согласия; и потенциальные преимущества для кодирования SSA, чтобы сделать этот вывод более чистым; и преимущество маскирования старших бит при маскировании младших битов.

Я бы просто удалил управляемые объекты более высокого уровня и управляемый сборщик мусора из wasm, удалил его из будущих функций

Я категорически не согласен с этой точкой зрения. Управляемые объекты не упрощают жизнь разработчикам компиляторов с управляемых языков. Основная осязаемая особенность, которую в будущем будет использовать управляемая память для wasm, будет заключаться в том, чтобы разрешить любое взаимодействие с остальным миром JavaScript (что выходит за рамки отправки массивов байтов туда и обратно).

Там нет никакого способа , вы можете реализовать (потенциально круговые) ссылки из wasm памяти объектов JavaScript в линейной модели памяти. Если это основное требование в конечном итоге не будет выполнено, нет никакой надежды на то, что такие языки, как ClojureScript, Scala.js или любой другой язык компиляции в JS, обеспечивающий приличную совместимость с JavaScript, будут скомпилированы до wasm.

Компилировать внутриязыковые функции до чего угодно очень просто. Нам для этого не нужна целевая поддержка. Однако компиляция межъязыковых функций невозможна без поддержки со стороны цели. IMO wasm в конечном итоге должен предоставить нам все инструменты для взаимодействия с объектной моделью JavaScript (и через эту общую модель между языками компиляции в wasm). А для этого требуется модель управляемой памяти, встроенная в спецификацию wasm (возможно, как расширение, если мы хотим обозначить ее таким образом).

@sjrd Было бы хорошо подробно

• отображение целого числа в песочнице wasm на объект JS, но это кажется вполне возможным с использованием хэш-таблицы или массива, просто остается, насколько это эффективно и насколько эффективно это должно быть? Это уже делается в играх и т. Д. Возможно, можно будет использовать более эффективный хэш, отвечающий требованиям безопасности указателей, поэтому давайте рассмотрим это, если необходимо.

• вы также поднимаете вопрос о циклических ссылках, поэтому я предполагаю, что вас беспокоит то, как JS GC может очистить эти указатели GC, хранящиеся в виде целых чисел в виртуальной машине wasm? Но как насчет указателей из JS на объекты в линейной памяти?

Эти проблемы нельзя решить в целом, добавив управляемые объекты и управляемый сборщик мусора в wasm, если только не было признано, что в целом код wasm использует управляемые объекты и управляемый сборщик мусора, и это в основном означает отказ от основного проекта wasm, чтобы преобразовать его в проектирование ВМ более высокого уровня.

Таким образом, мы могли бы изучить некоторые решения: ловушку JS GC, которая вызывает песочницу wasm для очистки указателей, которые могут ссылаться на объекты JS и у которых будет определенный способ передачи их обратно в JS GC. Это может быть всего лишь несколько определенных вызовов FFI, которые не добавляют нагрузки к дизайну ядра wasm и песочнице. Это тот тип мышления, который необходимо проявлять, не поддаваясь соблазну полагаться на васма для решения всех проблем.

@sjrd Вы также можете найти «распределенную сборку мусора», которая может быть фреймворком, который может решить ваш вариант использования, не обременяя wasm. Я не уверен, есть ли у JS вся необходимая поддержка, но может быть более общий интерес к добавлению этой поддержки в JS, если это необходимо, для хранилищ облачных объектов и т. Д., И это можно было бы сделать за пределами wasm CG. Сторона wasm будет просто целочисленным кодом wasm, поэтому может быть отдельным проектом (или несколькими проектами, если поставщики веб-браузеров и / или веб-сообщество не могут согласиться). Возможно, для многих приложений простые стратегии, такие как подсчет ссылок, слабые указатели и арендованные указатели, были бы адекватны без сложной глобальной сборки мусора для экземпляров wasm и JS. Другой вариант может заключаться в том, чтобы посмотреть, можно ли переместить в песочницу больше JS-кода из этих фреймворков - напишет ли кто-нибудь JS-интерпретатор для wasm, который имеет адекватную производительность для разного JS-кода, который является небольшой частью более крупной базы кода.

@ Россберг-хром,

Ясно, что явная пометка / снятие тегов необходима для целых чисел, но каков вариант использования для различения упакованных и распакованных ссылочных типов в системе типов? Есть ли какая-либо операция с неупакованной ссылкой, которая не может быть предоставлена ​​напрямую для упакованной ссылки? В этом случае вам не нужно вводить первое.

Вы не знаете, содержит ли Box ссылку или нет. В таком случае операция с указателем непосредственно на Box (что само по себе не является проблемой) должна будет проверять бит указателя и удалять любой тег. Операция указателя на Ptr никогда не потребовала бы этого. Так что, с моей точки зрения, это было просто соображением эффективности.

@ lars-t-hansen, а, значит, необработанные указатели IIUC будут напечатаны, а упакованные - нетипизированы? AFAICS, это не та факторизация, которую вы хотели бы, потому что тогда для каждого доступа через указатель в штучной упаковке сначала потребуется проверка во время выполнения, а указатель в штучной упаковке - это единственное, что вы можете сохранить в памяти с GC. Таким образом, обход графа памяти потребует проверки во время выполнения на каждом краю.

Я имел в виду нечто немного иное: семейство непрозрачных ссылочных типов ref(T) , где T - это либо структура / массив, функция (то есть указатели на функции), либо целое число (то есть помеченные целые числа). Кроме того, у вас есть тип anyref который является объединением / супертипом всех ссылок, и для которого вы можете выполнять тесты типов и проверенные понижающие преобразования. Таким образом, вам понадобится только тест во время выполнения, когда вы действительно имеете дело с объединением. Более того, null будет значением в типе anyref , но не в ref(T) , так что нулевые проверки также могут быть изолированы и явны в коде.

@ rossberg-chromium, действительно, я умалчал о том, как, по моему мнению, мы будем отслеживать здесь информацию о типах. В какой-то момент я представил, что Boxes может отслеживать информацию о типе, то есть Box (Ptr), где T - тип структуры, приведет к получению данных, которые, как известно, содержат либо помеченный указатель на T, либо (помеченное) целое число. В этом случае при прямом разыменовании блока все равно потребуется проверка на указатель (это может быть int), и все равно потребуется удалить тег (поскольку в теге установлены неизвестные биты).

Ваша идея ref (T) явно связана, но не позволяет помечать указатель, если я правильно понимаю, по крайней мере, не с помощью пользовательских тегов, что является проблемой, которую я пытался решить с помощью своего дизайна.

(+1 при ограничении nullptr каким-то образом через систему типов, однако я думаю, что это ортогонально тегам.)

@ lars-t-hansen, понятно. Что ж, я думаю, что набор текста - это суть функции тегов. Теперь, когда я думаю об этом еще раз, я действительно не понимаю, как вы могли бы достичь этого без явного введения тегированных типов или типов суммы в систему типов Wasm (за исключением некоторой формы зависимых типов, которых, я думаю, мы хотим избежать).

Но если нам все равно нужна какая-то форма тегированных типов, то кажется более привлекательным полностью смоделировать тегирование на этом более высоком уровне абстракции, а не вмешиваться в самый низкий уровень значений указателя. Это дает реализациям необходимую свободу действий для хранения тегов наиболее подходящим для них способом и позволяет избежать зависимости как от архитектуры, так и от виртуальной машины или ограничения тегов общим знаменателем. Например, для V8 поддержка более 1 дополнительного бита тега для указателей по существу потребовала бы повторной реализации половины V8, на что мы вряд ли подпишемся - тем более, что это повлечет за собой значительную стоимость памяти на 32-битных платформах. С другой стороны, в V8 будет множество способов эффективного хранения более крупных тегов на карте («скрытый класс») значения кучи без потери места для каждого значения.

@wllang

Было бы хорошо детализировать эти «проблемы», чтобы их можно было решить.

Я согласен. Я планировал сделать это в течение некоторого времени, но еще не успел это сделать.

отображение целого числа в песочнице wasm на объект JS, но это кажется вполне возможным с использованием хэш-таблицы или массива, просто остается, насколько это эффективно и насколько эффективно это должно быть?

ИМО, он должен быть по крайней мере таким же эффективным, как написание того же кода, управляющего объектами кучи в JavaScript . Я не думаю, что мы сможем приблизиться к этому уровню производительности с помощью целочисленной карты.

Судя по нескольким вашим сообщениям здесь и в других темах, вы, похоже, очень обеспокоены производительностью ядра wasm, когда дело касается неуправляемых языков. Тем не менее, что касается управляемых языков и их приоритетов, вы избавляетесь от основных проблем с помощью обходных решений, которые по своей сути неоптимальны с точки зрения производительности по сравнению с более глубокой интеграцией с wasm. Почему мы должны так различать управляемые языки?

Эти проблемы нельзя решить в целом, добавив управляемые объекты и управляемый сборщик мусора в wasm, если только не было признано, что в целом код wasm использует управляемые объекты и управляемый сборщик мусора, и это в основном означает отказ от основного проекта wasm, чтобы преобразовать его в проектирование ВМ более высокого уровня.

К нему можно обратиться, например, если у wasm есть два пространства памяти: линейная память, которую он имеет сейчас, в основном используется неуправляемыми языками, компилируемыми в wasm; и куча с GC, поддерживающая совместный сборщик мусора с кучей JavaScript, в основном используется управляемыми языками, компилируемыми в wasm. Обратите внимание, что управляемый язык, вероятно, также будет использовать линейную память для выделения памяти вне кучи (например, ByteBuffer.allocatedDirect() в Java); и неуправляемые языки, вероятно, также будут использовать управляемую память для сценариев взаимодействия с JavaScript.

Это может быть всего лишь несколько определенных вызовов FFI, которые не добавляют нагрузки к дизайну ядра wasm и песочнице.

Я не эксперт по сборке мусора, но у меня есть ощущение, что «всего несколько публично указанных хуков в сборку мусора» вполне могут стать серьезным бременем для разработки ядра wasm и / или реализации виртуальной машины.

Другой вариант может заключаться в том, чтобы посмотреть, можно ли переместить в песочницу больше JS-кода из этих фреймворков - напишет ли кто-нибудь JS-интерпретатор для wasm, который имеет адекватную производительность для разного JS-кода, который является небольшой частью более крупной базы кода.

Это повлечет за собой значительно более высокую общую нагрузку для всех участников. И TBH, кажется действительно абсурдным реализовать виртуальную машину JS внутри wasm, когда wasm в большинстве случаев привязан к реальной виртуальной машине JS. Кроме того, он не решает проблему взаимодействия с API-интерфейсами браузера, которые по сути являются API-интерфейсами JavaScript.

@sjrd

ИМО, он должен быть по крайней мере таким же эффективным, как написание того же кода, управляющего объектами кучи в JavaScript. Я не думаю, что мы сможем приблизиться к этому уровню производительности с помощью целочисленной карты.

Индексирование в массив выполняется быстро, возможно, требуется несколько инструкций машинного кода. Поиск по хешу похож на попадание. JS JIT использует множество кешей с таблицами и тестами внутри, поэтому, возможно, производительность будет характерной для JS.

Судя по нескольким вашим сообщениям здесь и в других темах, вы, похоже, очень обеспокоены производительностью ядра wasm, когда дело касается неуправляемых языков. Тем не менее, что касается управляемых языков и их приоритетов, вы избавляетесь от основных проблем с помощью обходных решений, которые по своей сути неоптимальны с точки зрения производительности по сравнению с более глубокой интеграцией с wasm. Почему мы должны так различать управляемые языки?

Если вы определяете «управляемые языки», это может звучать иначе :) Wasm должен быть в состоянии поддерживать эффективные объектные системы, написанные в основном коде wasm и хранящиеся в линейной памяти wasm, и этот код будет «управлять» объектной системой для другой код, написанный в песочнице, и я уже несколько лет работаю над повышением производительности для этого варианта использования. Так что у меня нет предубеждений против «управляемого» кода в целом, я не сосредоточен только на производительности кода C.

Случай, который вас беспокоит, - это интеграция с объектами, управляемыми средой выполнения JS, работающей в том же адресном пространстве процесса. Но допустим, что реализация wasm хотела поместить песочницу wasm в отдельный изолированный процесс, тогда вы уже вышли за рамки варианта использования, который вас беспокоит - и размещение экземпляра wasm в отдельном процессе может быть убедительным для безопасность и производительность.

К нему можно обратиться, например, если у wasm есть два пространства памяти: линейная память, которую он имеет сейчас, в основном используется неуправляемыми языками, компилируемыми в wasm; и куча с GC, поддерживающая совместный сборщик мусора с кучей JavaScript, в основном используется управляемыми языками, компилируемыми в wasm.

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

Я не эксперт по сборке мусора, но у меня есть ощущение, что «всего несколько публично указанных хуков в сборку мусора» вполне могут стать серьезным бременем для разработки ядра wasm и / или реализации виртуальной машины.

Определение некоторых имен импортируемых / экспортируемых функций не является бременем для дизайна wasm, но нагрузка на реализацию JS GC может быть значительной и над чем следует подумать, если глобальный GC является препятствием для демонстрации.

Это повлечет за собой значительно более высокую общую нагрузку для всех участников. И TBH, кажется действительно абсурдным реализовать виртуальную машину JS внутри wasm, когда wasm в большинстве случаев привязан к реальной виртуальной машине JS. Кроме того, он не решает проблему взаимодействия с API-интерфейсами браузера, которые по сути являются API-интерфейсами JavaScript.

Бремя для потребителей отходов будет намного меньше! Гораздо более низкая поверхность атаки. Это также может обеспечить более высокую производительность и более безопасные реализации (в отдельном процессе). Кроме того, это будет намного меньшая нагрузка на дизайн, что кажется очень значительным - сколько усилий и ресурсов вы ожидаете, чтобы развернуть функцию в веб-браузерах (если это вообще возможно), по сравнению с привлечением людей для написания реализации. Что касается функции ядра wasm, оцените ли вы в десять раз больше ресурсов или в сто раз больше, и каковы шансы на успех, возможно, один из десяти или один из ста?

Также, возможно, не так уж "абсурдно", учитывая, что экземпляр wasm может находиться в отдельном процессе, что wasm может связываться с кодом виртуальной машины, который может быть кэширован, и что веб-браузеры могут объединять версию и механизм для ее замены. Представьте, что вы можете выбрать или обновить вашу виртуальную машину JS (для использования в песочнице wasm), поменять ее на другую версию для отладки и т. Д. Также имейте в виду, что это также касается открытия экосистемы, разделения JS до некоторой степени, поэтому люди могут включать крошечный базовый интерпретатор или микропитон, или LUA, или CIL VM, или JVM и т.д.

Я бы поддержал доступность API-интерфейсов JavaScript нижнего уровня для экземпляров wasm без необходимости иметь дело с объектами JS, больше похожими на уровень ОС, и это кажется вполне возможным.

Я бы также поддержал, чтобы кодировка wasm была достаточно гибкой, чтобы выразить желаемую виртуальную машину JS, что не кажется таким большим бременем и в любом случае поможет вам в будущем. Мне просто интересно, доживу ли я до того, чтобы увидеть в сети высокопроизводительную низкоуровневую виртуальную машину.

@ Россберг-хром

С другой стороны, в V8 будет множество способов эффективного хранения более крупных тегов на карте («скрытый класс») значения кучи без потери места для каждого значения.

Fwiw это действительно звучит немного странно, предлагая хранить теги указателя в объекте "класса", потому что теги указателя, обсуждаемые здесь, предназначены для каждого указателя, а не для каждого класса, возможно, v8 действительно хранит указатели более чем в одном слове, но это было бы удивительно и интересный дизайн? Также было бы невозможно сохранить эти теги в объекте, на который указывает указатель, потому что объект может быть непосредственным значением, закодированным в битах тега.

@sjrd Просто чтобы установить, что проблема GC имеет решения, поднятые на этом форуме (патенты), вот одно решение. JS GC добавляет новую таблицу, которая сопоставляет указатели JS и целые числа (указатели стороны wasm). Он может поддерживать сторону wasm таблицы непосредственно в линейной памяти, поэтому таблица JS ссылается на буфер массива и диапазон. С каждой стороны есть флаг live и счетчик ссылок на указатель. Когда указатель добавляется к таблице живой флаг установлен и счетчик ссылок на один набор на той стороне стола. Когда сборщик мусора на любой стороне запускается, он откладывает очистку этих таблиц до последнего, поэтому в этот момент он знает, есть ли у этих указателей на соответствующей стороне активные указатели с этой стороны за пределами таблицы, и обновляет текущий флаг для соответствующей стороны. Если активный флаг снят, а счетчик ссылок на другой стороне равен нулю, то указатель восстанавливается и удаляется из таблицы. После обработки всех этих таблиц сборщик мусора продолжает очищать живые указатели, сохраняя все, на что они ссылаются, в реальном времени. На стороне JS, эти указатели являются либо только для записи или становятся нечитаемыми раз помечено как не жить на стороне JS - сторона wasm GC можно было бы ожидать , чтобы следовать тем же семантику (линейная память держит таблицу остается читаемым , но код навязывает инвариант объектной системы, что они не читаются). После GC на любой стороне запускается асинхронный вызов, если есть указатели, отмеченные как неработающие , это может вызвать другую сторону для обновления счетчика ссылок, и когда он станет нулевым, указатель будет возвращен на следующий GC. Эти таблицы могут использоваться для глобального GC для хранилищ объектов вне одного и того же потока, и сообщество JS может вызвать гораздо больший интерес к такой функции.

@wllang , карты / скрытые классы - распространенный метод реализации для отслеживания представления отдельных значений; они лишь слабо связаны с понятиями класса на уровне языка.

@ rossberg-chromium Насколько я понимаю, скрытые классы в v8 хранятся как слот в объекте. Этот PR касается помеченных указателей, поэтому даже хранение тегов в отдельном слоте объекта не кажется актуальным, немного одиноких, хранящих их в скрытом классе, скорее они должны храниться в указателе, поэтому реализация может быть свободна только для решения, какие биты указателей для использования. Или у вас было что-то еще, чего я просто не понял. Возможно, эти слайды помогут другим http://thlorenz.com/talks/demystifying-v8/talk.pdf

@wllang , я сказал, что, вероятно, не имеет смысла раскрывать _ где_ теги на самом деле хранятся, потому что архитектуры и виртуальные машины имеют серьезные и совершенно разные ограничения. Поддержка тегов для Wasm должна быть достаточно абстрактной, чтобы можно было реализовать несколько стратегий.

Включено в предложение GC (https://github.com/WebAssembly/gc/) как возможное расширение.

Привет, @ lars-t-hansen и @qwertie, здесь я буду

• Функция Pyret reactor функция big-bang DrRacket дают вам первоклассную абстракцию цикла событий на языке программирования. Вам нужна какая-то поддержка, подобная продолжению, чтобы реализовать ее в браузере.

• Функция DrRacket send/suspend (с тех пор, как она имитируется фреймворком Smalltalk Seaside и множеством других) - для серверного веб-программирования в прямом стиле - требует почти полного продолжения и ее легко реализовать, если они у вас есть.

Обратите внимание, что ни один из них не является сам по себе call/cc - это несвязанная, изящная абстракция программиста, которую просто так легко построить с продолжениями и невозможно построить без нее.

Разработчики как WeScheme [http://www.wescheme.org/], так и Pyret [https://www.pyret.org/] массово заплатили за его отсутствие. Оба мучительно, медленно, изо всех сил стараются добиться этого путем преобразования программы, чтобы включить такие функции, с огромным снижением производительности _и_ сложностью.

Если вы создаете свой собственный _пользовательский язык программирования_, вполне разумно сказать: «Я постановляю, что не будет нелокальной передачи управления». Если вы создаете _assembly_, я чувствую, что вы должны думать не только о том, что «продолжения - это странно, и только Scheme есть они в любом случае, и кто использует Scheme в этом отношении», и учитывать большое количество примитивов управления выполнением, которые есть в современных языках, и люди продолжают изобретать .

Поскольку разработчики браузера решили не поддерживать ни продолжения, ни сопрограммы / переключение стека, это спорный вопрос, но мне любопытно - можете ли вы описать, что делают эти функции, чтобы я мог понять, почему невозможно создать эти функции с использованием сопрограмм. / переключение стека как примитив?

По большей части достаточно сопрограмм. Они непременно сделают трюк
здесь.

Привет, @shriram , будьте уверены, что мы думаем за пределами C ++ и не рассматриваем эти функции как что-то странное или неважное. Их поддержка стоит на повестке дня после MVP. Мы можем не обязательно добавлять общий вызов / cc, но не исключены и более ограниченные формы ограниченных продолжений. Одним из возможных направлений могут быть обработчики алгебраических эффектов - у нас уже есть предложение по структурированной обработке исключений, и добавление возобновления, возможно, было бы «самым простым» путем к обеспечению структурированной формы «переключения стека» и включению всех упомянутых вами абстракций элементов управления. .