5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
> 1/ even 4KB granularity is quite a lot (the expected waste is at least 2KB per thread)
Про это я тоже писал! Когда там висит весь спринг, разницы особо нет.
А как можно оптимизировать стек под виртуальный тред онли?
Читать полностью…
вспомнил кейс smallrye messaging (подотносительно Quarkus)
тайм-аут по умолчанию 60 сек воспринимается как сообщение, которое нельзя обработать и общение с Kafka и данным консьюмером блокируется.
я скорее к тому, что там действительно уже все сильно зависит от внешней системы, к подтверждению твоих слов как конкретный кейс
И в реальных системах никто пулы на 1к потоков не делает, а значит там будет базовый пул потоков + очередь, и эта очередь будет забиваться
Читать полностью…
/channel/jvmchat/623423
Смотрим на res, дальше проецируем, что будет, когда в стеке окажется реальный код, а не два фрейма.
Ну хип тоже virtual memory как бы
История скорее всего про аллокацию при создании. Только зачем их обязательно создавать-то, а не брать из пула?
ну вообще огромные страницы иногда дают ОГРОМНЫЙ буст из за меньшего кол-ва tlb miss'ов
Читать полностью…
Вы не можете так же эффективно создавать и уничтожать тысячи платформенных потоков, как виртуальные
Читать полностью…
тогда я наверное не понял. А что именно еще можно было бы оптимизировать в стеках?
Читать полностью…
Посмотрел(пролистал), честно говоря для оптимизации размера стэка особо ничего не увидел
в основном касается оптимизации копирования фреймов virtual thread continuation <-> platform thread stack
по оптимизации размера увидел планируемую в будущем компрессию фреймов, все (
ну если говорить про внешнюю систему, то там вообще ещё надо помнить про poison pill
Читать полностью…
И тут уже зависит от того, насколько долго внешняя система будет отвечать
Читать полностью…
ну если получится доказать про память, то ок
но про параллельность /конкурентность все равно же в jdbc cp упрется
Я уверен, что решение на виртуальных потоках:
Позволит обработать каждое сообщение в батче параллельно
Будет стоить меньше по памяти, чем платформенный тред (на платформенных мы можем вылетать по OOM при ограниченных ресурсах)
Будет быстрее