pro.jvm

17 Dec 2024 07:21

По поводу стека в теории при суспенде его нужно сохранять в память. Соответственно памяти должно больше использоваться при глубоких стеках(могу говорить неправильно, но логика по идее такая).

Это опять же если отталкиваться от парадигмы что мы создаём кучу виртуальных потоков.

pro.jvm

17 Dec 2024 06:08

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

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

вообще изначальная задача прикрутить пагинацию к этому чудовищц через Pageable. но проблема возникает именно в генерируемом коде, когда перед Pageable приписывается аннотация @RequestParam, из-за которой спринг не понимает, что параметры урла типа &page=0&sort=date надо засунуть в Pageable

pro.jvm

17 Dec 2024 01:06

Запрашивается сразу целиком, но выделяется только по мере чтения и записи по адресам. Это вообще механизм операционки как таковой, когда -Xmx запросит сколько-то гигабайтов хипа, они тоже не будут реально выделены до того момента, пока куча не разрастется, есть даже -XX:+AlwaysPreTouch (который как раз проходит по хипу и трогает каждую страницу) для тех, для кого это может представлять проблему.

pro.jvm

17 Dec 2024 01:03

Я думал, что память на платформенные потоки алоцируется сразу

pro.jvm

17 Dec 2024 00:58

И если главная проблема это не context switching - то толку от виртуальных поток не много?

pro.jvm

17 Dec 2024 00:55

Благодарю за развернутый ответ

pro.jvm

17 Dec 2024 00:33

В памяти
Виртуальные же весят около килобайта

pro.jvm

17 Dec 2024 00:32

В том, что вместо 1000 платформенных поток на каждое сообщение, мы создадим 10 платформенных и 990 виртуальных, которые дешевле

pro.jvm

17 Dec 2024 00:28

А что?
Не совсем понимаю

pro.jvm

17 Dec 2024 00:27

Потому что платформеный в разы тяжелее виртуального ?

pro.jvm

17 Dec 2024 00:25

Ну вот упала 1000 сообщений
На них создается 1000 платформеных
Вместо того что бы плодить платформенные - у нас есть тред пул с 10 который на каждое сообщение будет создавать виртуальные и обслуживать их

pro.jvm

17 Dec 2024 00:23

На сообщение которое упадёт в консьюмера*

pro.jvm

17 Dec 2024 00:22

Так памяти не будет меньше расходоваться

pro.jvm

17 Dec 2024 00:18

где виртуальные треды избавляют от мемори оверхеда?

pro.jvm

16 Dec 2024 16:36

А сам сервак запускает виртуальный поток на http запрос для обработки этого запроса?

pro.jvm

17 Dec 2024 07:19

Для дефолтного разраба изменения в упрощении написания конкаренси кода. Работа с io не меняется с точки зрения кода. Проблемы с тяжелыми CPU задачами остаются.

Хотя надо глянуть, вроде можно суспенд сделать явно, если так, то тут тоже упрощение.

pro.jvm

17 Dec 2024 01:06

Благодарю, теперь все понятно

pro.jvm

17 Dec 2024 01:03

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

pro.jvm

17 Dec 2024 01:00

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

pro.jvm

17 Dec 2024 00:57

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

pro.jvm

17 Dec 2024 00:55

Нет. Метадата может и килобайт, но нас в первую очередь волнует стек.
С формальной точки зрения выглядит так, что на каждый нативный тред сразу отпиливается %stack size%, который может быть и мегабайтом, но эта память реально не выделяется, пока кто-то туда не попытается что-то записать (есть ещё нюанс с vm.overcommit, но его мало кто трогает). Если стек у треда отжирает сто килобайт, то что виртуальный, что нативный займут в памяти пространства одного и того же размера + метадата.
Следующий момент это то, что этот стек как правило на втором плане по сравнению с теми проблемами по памяти, которые создаются за счёт аллокации объектов в куче. Если в приложении будет memory pressure, то скорее по другим причинам.
С виртуальными тредами гораздо интереснее то, что по сравнению с нативными между ними весьма и весьма проще переключаться. Переключение тредов в операционке сопряжено с большим количеством необходимых операций, которые в целом не нужны, если мы хотим передать контроль внутри одного процесса.

pro.jvm

17 Dec 2024 00:32

Дешевле в какой валюте?

:D

pro.jvm

17 Dec 2024 00:30

Ну в чём конкретно выгода от виртуальных тредов? Их использование даст вздохнуть каким именно ресурсам и облегчит какие именно проблемы?

pro.jvm

17 Dec 2024 00:28

Тяжелее в каком именно качестве?

(потому что это не память)

pro.jvm

17 Dec 2024 00:27

А в чем выгода? Почему не иметь 1000 платформенных?

(ответ на самом деле весьма конкретен, я просто хочу довести до него)

pro.jvm

17 Dec 2024 00:24

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

pro.jvm

17 Dec 2024 00:22

Так если будет пул с нескольки платформенных, которые на консьюмера будут выделять по одному виртуальному
Не будет ли это выгоднее ?

pro.jvm

17 Dec 2024 00:20

Приходит 1000 сообщений которые нужно куда то отправить и забить
Зачем на каждый выделять по платформ треду?

pro.jvm

17 Dec 2024 00:16

А как идея использовать виртуальные треды для Кафка консьюмеров флоу которых в конце-концов упираются в IO вызов ?
Что бы избавиться от лишнего мемори оверхеда

pro.jvm

16 Dec 2024 11:58

Вот я бы вообще не стал такого делать