pro.jvm

17 Dec 2024 08:52

ну вообще огромные страницы иногда дают ОГРОМНЫЙ буст из за меньшего кол-ва tlb miss'ов

pro.jvm

17 Dec 2024 08:51

Вы не можете так же эффективно создавать и уничтожать тысячи платформенных потоков, как виртуальные

pro.jvm

17 Dec 2024 08:50

В комментариях первый чел - из команды Loom

pro.jvm

17 Dec 2024 08:49

тогда я наверное не понял. А что именно еще можно было бы оптимизировать в стеках?

pro.jvm

17 Dec 2024 08:46

Посмотрел(пролистал), честно говоря для оптимизации размера стэка особо ничего не увидел
в основном касается оптимизации копирования фреймов virtual thread continuation <-> platform thread stack
по оптимизации размера увидел планируемую в будущем компрессию фреймов, все (

pro.jvm

17 Dec 2024 08:32

Смотря сколько подов)

Можно и до 10/50 понизить

pro.jvm

17 Dec 2024 08:31

Даже с балансером соединений

pro.jvm

17 Dec 2024 08:30

Что ты имеешь в виду?

pro.jvm

17 Dec 2024 08:28

ну если говорить про внешнюю систему, то там вообще ещё надо помнить про poison pill

pro.jvm

17 Dec 2024 08:26

Чем дольше, тем выгоднее решение на виртуальных

pro.jvm

17 Dec 2024 08:26

И тут уже зависит от того, насколько долго внешняя система будет отвечать

pro.jvm

17 Dec 2024 08:25

ну если получится доказать про память, то ок
но про параллельность /конкурентность все равно же в jdbc cp упрется

pro.jvm

17 Dec 2024 08:22

Я уверен, что решение на виртуальных потоках:

Позволит обработать каждое сообщение в батче параллельно
Будет стоить меньше по памяти, чем платформенный тред (на платформенных мы можем вылетать по OOM при ограниченных ресурсах)
Будет быстрее

pro.jvm

17 Dec 2024 08:20

Я уже два раза писал, почему нет (:

pro.jvm

17 Dec 2024 08:14

Да норм идея, паттерн мульти трэдед консьюмер, где требуется обработка батча параллельно + тут поможет структурное конкарренси

pro.jvm

17 Dec 2024 08:52

> 1/ even 4KB granularity is quite a lot (the expected waste is at least 2KB per thread)

Про это я тоже писал! Когда там висит весь спринг, разницы особо нет.

pro.jvm

17 Dec 2024 08:51

> managing virtual memory is relatively expensive

ээээ

pro.jvm

17 Dec 2024 08:50

https://www.reddit.com/r/java/s/XWu7HnGXiQ

pro.jvm

17 Dec 2024 08:49

А как можно оптимизировать стек под виртуальный тред онли?

pro.jvm

17 Dec 2024 08:38

вспомнил кейс smallrye messaging (подотносительно Quarkus)
тайм-аут по умолчанию 60 сек воспринимается как сообщение, которое нельзя обработать и общение с Kafka и данным консьюмером блокируется.
я скорее к тому, что там действительно уже все сильно зависит от внешней системы, к подтверждению твоих слов как конкретный кейс

pro.jvm

17 Dec 2024 08:31

У меня подов может быть быть десятки и сотни…

pro.jvm

17 Dec 2024 08:31

Это много для условного постгреса

pro.jvm

17 Dec 2024 08:30

На под 20-40 соединений в jdbc, mvc пул сотка

pro.jvm

17 Dec 2024 08:27

И в реальных системах никто пулы на 1к потоков не делает, а значит там будет базовый пул потоков + очередь, и эта очередь будет забиваться

pro.jvm

17 Dec 2024 08:26

/channel/jvmchat/623423

Смотрим на res, дальше проецируем, что будет, когда в стеке окажется реальный код, а не два фрейма.

pro.jvm

17 Dec 2024 08:26

Ага, только платформенные блокируются

pro.jvm

17 Dec 2024 08:23

есть ситуации, но безотносительно кафки, конечно

pro.jvm

17 Dec 2024 08:21

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

pro.jvm

17 Dec 2024 08:17

главная идея использования virtual threads в kafka consumer это именно уход от проблемы context switching.
Про память ещё доказать надо :)

pro.jvm

17 Dec 2024 07:56

Там предположение, что код будет делать fan-out для параллельных тасок, и у них будет минимальный стек.