openjdk.ruOpenJDK на русском

JEP 188: Java Memory Model Update

Обновление модели памяти Java (Java Memory Model)

ОтветственныйDoug Lea
ТипInformational
ОбластьJDK
СтатусDraft
Обсуждениеjmm dash dev at openjdk dot java dot net
ТрудоёмкостьM
ДлительностьXL
ОдобренBrian Goetz
Создан2013/12/16 20:00
Обновлён2025/01/14 21:28
Задача8046178

Аннотация

Этот JEP служит источником информации и ориентиром для работ, связанных с конкурентностью на основе общей памяти, в том числе для обновлений спецификаций Java SE, поддержки конкурентности в JVM, компонентов JDK, тестирования и инструментов. Инженерные работы и работы по выпуску в этих областях будут предметом других JEP, которые, в свою очередь, станут частями одного или нескольких JSR, нацеленных на крупный выпуск. В частности, обновления Java Language Specification (глава 17) требуют такого JSR.

Мотивация

Спецификация моделей согласованности общей памяти, а также разработка и сопровождение возможностей и компонентов, работающих в соответствии с ними, — одни из самых важных и вместе с тем самых сложных задач при создании конкурентных и параллельных платформ. Со временем проявляются ограничения спецификаций, ошибки и непредусмотренные последствия; появляются новые аппаратные платформы, приёмы программирования, программные компоненты и инструменты, которые выходят за существующие рамки. Этот JEP решает проблемы и расширяет охват модели памяти Java (Java Memory Model, JMM), последний раз пересмотренной для Java SE 5 в рамках JSR 133.

Описание

Результаты этого JEP будут размещены на OpenJDK Wiki. Работа будет вестись в основном в отдельной рассылке OpenJDK. Мы ожидаем, что в результаты войдёт следующее:

  1. Улучшенная формализация. Части базовой модели будут сформулированы заново. Мы стремимся к тому, чтобы пересмотренную модель можно было проверять автоматически и чтобы людям было проще её понимать. Когда она будет изложена в виде обновлений главы 17 JLS, это также устранит существующие ошибки, на которые указывал ряд научных статей. (Самую раннюю из них см. в работе «Java Memory Model Examples: Good, Bad and Ugly» Дэвида Аспинолла (David Aspinall) и Ярослава Шевчика (Jaroslav Ševčík).)

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

  3. Расширенная область охвата. Существующие спецификации явно охватывают потоки Java (Java Threads), блокировки, мониторы, а также поля volatile и final. Однако начиная с Java SE 5 были добавлены возможности, которые нельзя строго специфицировать в этих терминах (например, AtomicX.weakCompareAndSet). Их необходимо охватить. Мы также ожидаем, что в ходе работы над другими предстоящими JEP могут возникнуть и другие расширения.

  4. Совместимость с C11/C++11. Стандарты C++11 и C11 заимствовали идеи из работы над спецификацией JMM в JSR 133. Однако они также расширили их, охватив конструкции, которые были (или могут быть) добавлены в Java только после JSR 133 (см. выше). Отчасти потому, что Java-программы могут вызывать нативные библиотеки на C, эквивалентные конструкции в разных языках должны иметь совместимые спецификации. Мы также изучим, можно ли установить межъязыковые соглашения, которые обеспечат совместимость низкоуровневых реализаций этих конструкций на распространённых платформах.

  5. Рекомендации по реализации. Разработчикам JVM, разработчикам библиотек JDK и разработчикам в целом часто полезно опираться на документы, объясняющие, как JMM влияет на конкретные задачи и их решения. Мы намерены подготовить такие документы.

  6. Поддержка тестирования. Соответствие требованиям модели памяти трудно проверить тестами. Мы рассчитываем работать с инженерами, которые проектируют и реализуют тесты, имеющие чёткую основу в спецификациях.

  7. Поддержка инструментов. Переформулированную модель смогут использовать инструменты разработки ПО, которые путём анализа ищут ошибки, такие как состояния гонки, а также инструменты, проверяющие, что свойства безопасности сохраняются при конкурентном выполнении. Хотя проектирование и создание самих инструментов не входит в рамки этого JEP, он может предложить рекомендации по аннотациям, которые позволили бы проводить качественный статический и динамический анализ.

Риски и допущения

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

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

Если эта работа не достигнет своих целей, текущее положение дел сохранится.

Зависимости

Этот JEP не зависит ни от каких других. Мы ожидаем, что будущие JEP, связанные с конкурентностью, будут зависеть от этого JEP.