Кто-Нибудь видел, какая изначальная причина была при отказе от ThreadLocal

в лум? Начал тут разбирать как устроен ScopedValues, добравлся вот до этого(https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.base/share/classes/java/lang/Thread.java#L302) и чет немножко не понял, они так же лежат в поле треда, Бейтман на последнем JVMLS немного упоминает, что отказ от TL благотворно влияет на некоторые GC(хотя мне стало не понятно, почему). И тут становится не понятно, а почему линкед лист(которым по-сути и является Snapshot в ScopedValues) лучше, чем хешмапа в том же поле треда. По mail-листам тоже ничего особо не нашел. Особенно беспокоит, что альтернативы для пула объектов, которые раньше были в TL, работают хуже, глядя на тот jackson, который добавил BufferRecyclerPool(для loom-friendly).

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

Посмотрите на то, как сделаны ScopedValues. Это линкед-лист в поле потока.

Он immutable, по этому просто шарится как общий ресурс

So what? Иммутабельная мапа. Это ничего не объясняет.

Там очень ограниченный скоуп это легко контролить и прибирать

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

О каких проблемах ты говоришь? Дай контекста хоть

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

Никто не запрещает тебе юзать tl, просто на вирт тредах на большом количестве потоков это будет мягко говоря не эффективно. SV тоже поддерживают кеширования и прочие техники при надобности. См: java.lang.ScopedValue.cacheSize

Давай еще раз, каким образом TL будет менее эффективен, когда SV и TL это два поля, которые лежат в поле потока? Не предназначен SV для буферов, это примерно везде говорится.

Тредлокал привязан к платформенному треду

https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.base/share/classes/java/lang/Thread.java#L302 Они в одном месте находятся.

Максимально упрошу(для примера): что дешевле взять 1мб мутабельных данных и пошарь это на 1кк тредов копрованием. Или сделать тоже самое только просто раздавая реф на немутабельные данные. Выше тебе хорошее уточнение дали, что в у тебя ос тредов может быть 10, при этом поверх них вертеться будет 10лямов вирт. Цена доступа к данным показательна.

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

Раздел Motivation: https://openjdk.org/jeps/446

Ага, правда это никак не отвечает на мой вопрос, но спасибо.

Очевидно, меняется контракт, поэтому решили добавить новую реализацию

О каком контракте идет речь?

Для TL установленное значение доступно для треда пока тот существует и может меняться. Для SV - значение не меняется и доступно в пределах выполнения метода run + наследование контекста. Очевидно, не получится просто заменить одну реализацию на другую

Ну так можно было в ThreadLocal добавить скоуп с наследованием. Такое чувство, что должна быть более объективная техническая причина, почему нельзя было потюнить TL.

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

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

Ну считай они его и сделали опциональным. Если нужен скоуп - SV, если в пределах треда - TL. Как мне кажется, это не из-за тех.проблем, а из-за разных концепций

Но если это действительно изначальная причина, то я просто не видел Бейтман или Рон Прейслер именно об этой причине говорят.

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

Ну, ты же видишь, что они по-разному работают

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

А что не напишешь на майлинг лист вопросы эти? Они обычно радостно на такое отвечают

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