Есть ли примеры многопоточных компиляторов Tracing JIT?

Как JVM, так и .NET CLR включают компиляторы Just-In-Time, которые поддерживают несколько пользовательских потоков. Тем не менее, я считаю, что это JIT-методы, основанные на методах.Есть ли примеры многопоточных компиляторов Tracing JIT?

Все tracing JITs Я знаю, например, LuaJIT и PyPy, только однопоточные.

Есть ли примеры отслеживания JIT, которые поддерживают несколько пользовательских потоков? Если нет, существуют ли технические причины, почему они не существуют?

источник

2016-09-06 user200783

. NET поддерживает multicore jit. Но это, вообще говоря, не совсем универсальное решение, оно может только когда-либо иметь какой-либо заметный эффект, когда ядра остаются занятыми. Для этого требуется машина времени, она знает, какой метод, вероятно, будет использоваться далее. Решенный в .NET путем записи данных профиля, порядок выполнения методов. Таким образом, в течение * следующего * времени, когда программа запускается, они могут быть перекодированы раньше времени. Машины времени сложны, они говорят вам, что в 2015 году у людей есть вертолеты и летательные аппараты. Ну, навесы оказались правдой. –

@HansPassant - Использование фоновых потоков для JIT-компиляции кода интересно, я не знал, что .NET имеет эту функцию. Однако даже до того, как эта функция была добавлена, пользователи могли создавать несколько потоков, поэтому .NET JIT уже был необходим для компиляции кода на несколько потоков. AFAIK, хотя, .NET все еще JIT-компилирует один метод за раз.Мой вопрос конкретно посвящен [Отслеживание JIT] (https://en.wikipedia.org/wiki/Tracing_just-in-time_compilation): существуют ли какие-либо технические препятствия для JIT трассировки, которая компилируется по нескольким потокам (либо в фоновом режиме, либо в поддержка нескольких пользовательских потоков)? – user200783

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

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

Рассматриваете ли вы попытку написать собственный трассировочный многопоточный JIT? Это можно сделать, но оно задействовано.

источник

2016-09-13 17:34:48

AFAIK LuaJIT, например, решает, какой код для JIT основывается только на том, сколько раз он запускается, не используя информацию о времени. Поэтому я считаю, что его алгоритмы должны быть невосприимчивы к вопросам межпоточного кэширования, о которых вы говорите. Мне кажется, что нет никакой теоретической причины, по которой трассировка JITs не может поддерживать несколько потоков, но, возможно, такой JIT никогда не был реализован? _Вы считаете, что пытаетесь написать собственный трассировочный многопоточный JIT? _ Я рассматриваю возможность написания трассировки JIT, да. Я пытаюсь решить, является ли поддержка многопоточности правдоподобной целью для проекта. – user200783

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

Поддержка многопоточности в трассировке JIT правдоподобна. Вопрос только в том, насколько хорошо вы можете сделать оптимизацию. –

Ваш вопрос спорный из-за его неправильного помещения. Оптимизатор HotSpot для JVM/OpenJDK от Oracle составляет , а не «метод по времени JIT». Одной из его фундаментальных технологий является возможность создания, часто называемая «агрессивной вставкой», поскольку она делает спекулятивные встроенные методы, которые, скорее всего, являются объектом диспетчеризации динамических методов, основанные на профилировании текущего исполнения (и других подсказок). Это даже включает в себя возможность деоптимизации, если поведение во время выполнения программы изменяется, и он больше не выполняет оптимизированный путь кода.

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

Таким образом, с помощью JVM HotSpot у вас уже есть многопоточная оптимизирующая среда, использующая известные пути выполнения. Однако эту информацию не нужно собирать так, как описано в разделе «Трассировка». Поскольку этот JVM способен создавать моментальный снимок трассировки стека потока в любое время, он также может заглянуть в трассировку в определенные промежутки времени, имея больший контроль над служебными данными профилирования, чем добавление функции записи к каждому вызову метода. Таким образом, JVM может ограничить получение трасс потоками, фактически потребляющими значительное процессорное время, и будет по сути получать фактическую цепочку вызовов, даже если задействованные методы содержатся в нескольких цепочках вызовов разных потоков.

источник

2016-09-14 09:51:14 Holger

В качестве дополнения вы можете использовать опции '-XX: + UnlockDiagnosticVMOptions -XX: + PrintInlining', чтобы JVM печатал * деревья вызовов *, он будет inline. – Holger

Есть ли примеры многопоточных компиляторов Tracing JIT?

ответ

Смежные вопросы