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. Мы ожидаем, что в результаты войдёт следующее:
-
Улучшенная формализация. Части базовой модели будут сформулированы заново. Мы стремимся к тому, чтобы пересмотренную модель можно было проверять автоматически и чтобы людям было проще её понимать. Когда она будет изложена в виде обновлений главы 17 JLS, это также устранит существующие ошибки, на которые указывал ряд научных статей. (Самую раннюю из них см. в работе «Java Memory Model Examples: Good, Bad and Ugly» Дэвида Аспинолла (David Aspinall) и Ярослава Шевчика (Jaroslav Ševčík).)
-
Охват JVM. Существующие спецификации сосредоточены на конструкциях уровня языка. Из-за этого некоторые вопросы (например, инициализация) определены не полностью, особенно для других языков, работающих на JVM. Эти вопросы будут решены, возможно, за счёт построения базовой модели на минимальном наборе байт-кодов и интринсиков.
-
Расширенная область охвата. Существующие спецификации явно охватывают потоки Java (Java Threads), блокировки, мониторы, а также поля volatile и final. Однако начиная с Java SE 5 были добавлены возможности, которые нельзя строго специфицировать в этих терминах (например, AtomicX.weakCompareAndSet). Их необходимо охватить. Мы также ожидаем, что в ходе работы над другими предстоящими JEP могут возникнуть и другие расширения.
-
Совместимость с C11/C++11. Стандарты C++11 и C11 заимствовали идеи из работы над спецификацией JMM в JSR 133. Однако они также расширили их, охватив конструкции, которые были (или могут быть) добавлены в Java только после JSR 133 (см. выше). Отчасти потому, что Java-программы могут вызывать нативные библиотеки на C, эквивалентные конструкции в разных языках должны иметь совместимые спецификации. Мы также изучим, можно ли установить межъязыковые соглашения, которые обеспечат совместимость низкоуровневых реализаций этих конструкций на распространённых платформах.
-
Рекомендации по реализации. Разработчикам JVM, разработчикам библиотек JDK и разработчикам в целом часто полезно опираться на документы, объясняющие, как JMM влияет на конкретные задачи и их решения. Мы намерены подготовить такие документы.
-
Поддержка тестирования. Соответствие требованиям модели памяти трудно проверить тестами. Мы рассчитываем работать с инженерами, которые проектируют и реализуют тесты, имеющие чёткую основу в спецификациях.
-
Поддержка инструментов. Переформулированную модель смогут использовать инструменты разработки ПО, которые путём анализа ищут ошибки, такие как состояния гонки, а также инструменты, проверяющие, что свойства безопасности сохраняются при конкурентном выполнении. Хотя проектирование и создание самих инструментов не входит в рамки этого JEP, он может предложить рекомендации по аннотациям, которые позволили бы проводить качественный статический и динамический анализ.
Риски и допущения
Для успеха необходим вклад экспертов по конкурентности в области формальных спецификаций, аппаратной и программной инженерии и инструментов разработки ПО. Мы заранее сформировали ядро экспертизы, получив предварительное согласие на участие от учёных, исследователей и инженеров с обширным опытом и знаниями в этих областях. Мы и дальше будем привлекать к участию других экспертов.
В случае успеха мы ожидаем, что эта работа может привести к различным улучшениям, корректировкам и исправлениям ошибок во всей платформе. Также возможно, что некоторые редкие пограничные программные конструкции окажутся проблемными. Однако мы не ожидаем иного влияния на обратную совместимость или на несвязанные спецификации и API.
Если эта работа не достигнет своих целей, текущее положение дел сохранится.
Зависимости
Этот JEP не зависит ни от каких других. Мы ожидаем, что будущие JEP, связанные с конкурентностью, будут зависеть от этого JEP.