5916
Сообщество разработчиков Java Scala Kotlin Groovy Clojure Чат для нач-их: @javastart Наш канал: @proJVM Вакансии: @jvmjobs @jvmjobschat ⚠️ Оффтоп -> @flood ❌Переход на личности ❌Троллинг ❌Реклама ❌HH (вакансии) ❌Варез
https://www.youtube.com/watch?v=6nRS6UiN7X0 - тут показывалась, как они оптимизации делают для этого
Читать полностью…
Насколько понимаю, он и так в обычной куче лежит, его никуда двигать не надо, разве что регистрф сбрасывать (как и в нативных). Хороший вопрос - это как он расширяется, копированием (= медленно, но только до самой глубокой цепочки вызова) или ссылкой на следующую страницу (= не так медленно, но постоянно, потеря локалити, лишние инструкции)
Читать полностью…
По поводу стека в теории при суспенде его нужно сохранять в память. Соответственно памяти должно больше использоваться при глубоких стеках(могу говорить неправильно, но логика по идее такая).
Это опять же если отталкиваться от парадигмы что мы создаём кучу виртуальных потоков.
привет, может кто-то сталкивался с swagger-codegen, это штука для генерации кода но основе спецификации. в проект подключен как плагин. не понимаю откуда он берет шаблоны .mustache, возникла необходимость изменить шаблон, хотел взять исходный для примера.
пробовал взять шаблон из гитхаба, на судя по всему это не тот, т.к. куча ошибок при генерации. версию смотрел правильную.
вообще изначальная задача прикрутить пагинацию к этому чудовищц через Pageable. но проблема возникает именно в генерируемом коде, когда перед Pageable приписывается аннотация @RequestParam, из-за которой спринг не понимает, что параметры урла типа &page=0&sort=date надо засунуть в Pageable
Запрашивается сразу целиком, но выделяется только по мере чтения и записи по адресам. Это вообще механизм операционки как таковой, когда -Xmx запросит сколько-то гигабайтов хипа, они тоже не будут реально выделены до того момента, пока куча не разрастется, есть даже -XX:+AlwaysPreTouch (который как раз проходит по хипу и трогает каждую страницу) для тех, для кого это может представлять проблему.
Читать полностью…
Я думал, что память на платформенные потоки алоцируется сразу
Читать полностью…
И если главная проблема это не context switching - то толку от виртуальных поток не много?
Читать полностью…
В том, что вместо 1000 платформенных поток на каждое сообщение, мы создадим 10 платформенных и 990 виртуальных, которые дешевле
Читать полностью…
Ну вот упала 1000 сообщений
На них создается 1000 платформеных
Вместо того что бы плодить платформенные - у нас есть тред пул с 10 который на каждое сообщение будет создавать виртуальные и обслуживать их
Я к тому что да, он в куче. Но он там есть.
Просто складывается ощущение что стэка нет. Локальных переменных нет. И т д
Вот бесплатные треды.
В jep написано, что стэк не будет глубоким. Но непонятно почему.
да не могут виртуальные треды больше памяти сожрать, кроме как только фактом своего количества
Читать полностью…
Для дефолтного разраба изменения в упрощении написания конкаренси кода. Работа с io не меняется с точки зрения кода. Проблемы с тяжелыми CPU задачами остаются.
Хотя надо глянуть, вроде можно суспенд сделать явно, если так, то тут тоже упрощение.
Я боюсь использовать именно это словосочетание, но да, я говорю про возможные флаши кэшей и прочее при переключении нативных тредов. Если процесс сам внутри себя что-то сделал, о чём операционка даже не знает, то никаких таких пенальти не будет.
Читать полностью…
Там просто другие вещи выигрываются, разница в памяти есть, но она не будет сильно заметна. Вот здесь разница меньше чем в три раза (в реальном приложении стеки тредов будут потреблять микроскопический процент от общего объема памяти) достигается при пустом стеке.
Читать полностью…
То-есть
В целом, смысла в моей идее мало, потому что оверхед там генерируют не потоки сами по себе, а данные, которые в них забиваются ?
Нет. Метадата может и килобайт, но нас в первую очередь волнует стек.
С формальной точки зрения выглядит так, что на каждый нативный тред сразу отпиливается %stack size%, который может быть и мегабайтом, но эта память реально не выделяется, пока кто-то туда не попытается что-то записать (есть ещё нюанс с vm.overcommit, но его мало кто трогает). Если стек у треда отжирает сто килобайт, то что виртуальный, что нативный займут в памяти пространства одного и того же размера + метадата.
Следующий момент это то, что этот стек как правило на втором плане по сравнению с теми проблемами по памяти, которые создаются за счёт аллокации объектов в куче. Если в приложении будет memory pressure, то скорее по другим причинам.
С виртуальными тредами гораздо интереснее то, что по сравнению с нативными между ними весьма и весьма проще переключаться. Переключение тредов в операционке сопряжено с большим количеством необходимых операций, которые в целом не нужны, если мы хотим передать контроль внутри одного процесса.
Ну в чём конкретно выгода от виртуальных тредов? Их использование даст вздохнуть каким именно ресурсам и облегчит какие именно проблемы?
Читать полностью…
Тяжелее в каком именно качестве?
(потому что это не память)
А в чем выгода? Почему не иметь 1000 платформенных?
(ответ на самом деле весьма конкретен, я просто хочу довести до него)
Когда создается тред и выполняет какую-либо работу (платформенный или виртуальный - без разницы), то каким образом расходуется память?
Читать полностью…
Так если будет пул с нескольки платформенных, которые на консьюмера будут выделять по одному виртуальному
Не будет ли это выгоднее ?
Приходит 1000 сообщений которые нужно куда то отправить и забить
Зачем на каждый выделять по платформ треду?