У порівнянні із розмірами платформених потоків (>512Kb) проблеми із постійним переносом стеку в і з heap нема, бо стек віртуальних потоків на багато менший за платформений. Слід зазначити, але нема якогось навіть базового розміру стеку віртуального потоку, бо його розмір цілковито залежить від того який код в ньому запускається.

І так і ні. Якщо ваш код не використовує synchoronized, то не очікуйте, що віртуальний поток повернеться на той самий поток-носій після того як його відпаркують.

Мне грустно это признавать, но Харьков останется прифронтовым городом ибо эта война, как я не верил и не помогал ВСУ, но останется прифронтовым городом на долгие годы, если не десятилетие. Этот город не будет комфортным для жизни от слова совсем ибо не повезло географически.

П.С.: я в жизни не думал о переезде даже по Украине, но сейчас я не вижу других сценариев.

Увы, «вернуться в Харьков» не получается. Много кто попытался вернуться и в итоге уехал спустя 2-3 дня после интенсивных прилётов в центр города...

Увы, тенденция такова, что вялая и неудобная Европа, Канада и США в долгосрочной перспективе выходит стабильнее и безопаснее, нежели Украина.

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

Окружна, ну може трошки довше. Але навіть через місто я за 45 хвилин доїжджав з бот.саду до Горизонту.

Киев неграмотный мегаполис. Всегда возвращаясь из него я понимал прелести Харькова — весь город доступен в 25-40 минутах из любой точки. Имея возможность работать удаленно я лучше выберу около-европейский Львов, нежели хаотичный Киев.

Щоб зрозуміти мої плани я опишу фактичну ситуацію яка буде у всій країні у наступні 10 років:
1. Харків — прифронтове місто, вже ніколи не буде мільйоннико, навіть близько. Дніпро стане «новим Харковом» і остаточно прийме усіх, хто не хоче війни ближче ніж 150км до лінії фронту.
2. Буде розвиток міст типу Чернівці, Франик та Хмельницький. Вони приймуть тих, хто не хоче жити на лівому березі Дніпра.
3. Київ залишиться тим самим Київом як до війни — гарне місто для роботи, але кляте для життя.
4. Закарпаття залишиться селом, якщо не стане ще гіршим місцем а ніж було. Розвитку там не буде ні за яких умов.
5. Львів стане новим, але кращім Харковом. Львів стане більш ніж мільйонником, а це означає, що попит на житло зросте (це відбувається вже).

Отже, західні області — це не просто непогана ідея, це єдиний варіант де хоч в щось можна вкладати гривню, що втрачає у ціні. Але я вже мав справу із забудовниками у Львові. Те, що я бачу зараз це якийсь кошмар: якість забув на стільни низька, що аж соромно, але ціна наразі (вибачте) дурна. Навіть враховуючи різницю курсів, житло щось біля економ-класу (але його позиціонують як бізнес) вже на базі фундаменту вимагають 800-900$/кв.м., і це ще не межа.

Отже, я роблю наступні висновки: житло купувати в Україні це інвестиція типу «ставка на біле» у рулетці. Працюючи на міжнародну продуктову компанію і маючи, навіть, заробітню плату трохи нижче ринку мені краще купити житло у Великобританії за 250-300 тис. фунтів із рострочкою під смішні відсотки, а ніж знову втратити щось біля 100-150K USD в Україні без можливості хоч щось повернути.

План заощаджувати якомога більше. Ніяких витрат дорожче 500-1000$, і то не зрозуміло куда їх витрачати.

Житло в Україні? Нажаль на цьому поставили хрест, бо в нас в Харкові зависла недобудована квартира на 100К USD.

Я не вважаю себе песимістом, але ця війна перейде у вкрай-затяжну фазу і буде заморозки конфлікту по типу АТО, але тепер від Харкова до Запоріжжя і це лише питання часу.

Я ніколи не думаю за імміграцію. Але я точно буду шукати можливості іммігрувати свої активи подалі від рф, як мінімум за 2000-4000км від західного кордону.

разом із зміною курсу, НБУ зробив каку — суворі ліміти на перерахування. Тепер навіть Мавік 3 не купити закордоном, якщо що. Перерахувати комусь закордон теж не вийде. Суворі ліміти.

Так мова ж якраз і йде про функії сигнатура яких може місити обидва типи агрументів: іменовані та варіативні. Ну і наведений вами приклад є таким собі анти-паттерном, частіше за все першим аргументом йде іменований типу int, який відповідає за кількість варіативних аргументів. Отже, такий код є прикладом «як можна, але будь ласка не треба так робити».

Щось мало тут про автоматизацію. Додам від себе:
1. Tox — такий собі Make/Cmake для Python проектів.
2. Make — якщо ви пишете на CPython.
3. Podman — бо Docker не безкоштовний вже.
4. Flake8, hacking, black — для статичного аналізу коду.
5. GraalVM — замість інтерпретатора як залежності, для компіляції у машинний код.

Раніше ніж що? Це ж питання типу чому одразу було не зробити стандарт С++20, а почали із С++11.

не те щоб слоупоки, але нема жодних аргументів сидіти на чомусь новішому за 11-ю версію, але старішу за 17-ту, особливо враховуючи те, що в новіщій версії JDK вже є крутий GC — ZGC із паузами меншими за 10мс (сам це бачив).

1) Чому розробка Loom стартувала так пізно (2018), коли вже років 10 як існувало реактивне програмування з Reactor/RxJava, яке якраз і вирішувало проблеми з обмеженістю потоків у системі?

Влучне запитання, але досить невлучне порівняння, бо так можна сказати що механізм C EPOLL та SELECT існують не одне десятеліття. Правильною відповіддю буде те, що віртуальні треди впроваджуються не як конкурент до якоїсь технології по за межами JDK, а як розвиток самої платформи і тут вже питання часу не має жодного сенсу.

2) Чи віртуальні потоки є абсолютною best practices, тобто звичайними потоками більше не потрібно користуватися? Якщо ж ні, то коли потрібно скористатися звичайними, а коли віртуальними потоками?

На це питання є відповідь у статті. Віртуальні потоки для додатків що базуються на IO операціях, але якщо треба щось обчислити на CPU/GPU, то це справа для звичайних потоків.

Як передавати дані через ThreadLocal?

Так як і завжди, нема різниці. Але більш ефективним рішенням буде Extent Locals (openjdk.org/jeps/8263012), однак дизайн цієї фічі ще не зафіксований.

Наскільки стабільно працює Loom зараз? Чи можна спробувати його запустити в production в JDK 19? Якщо ні, то чому?

Я б сказав, що це одна з надпотужних фіч JDK наразі. Чи можна використовувати ії у продакшені — так, але фрейморків які підтримують цю технологію нема і навряд буде до офіційного релізу цієї фічі (після усіх Preview і коли вона дійде до статусу Standard Feature).

Кількість потоків-носіїв (carrier threads) у ForkJoinPool який відповідає за віртуальні треди за замовчанням дорівнює кількості наявних процессорів мінус один, але не менше одного. На мойому macbook pro 2018 їх кількість дорівнює трьом.

У статті ще зазначено, що кількість потоків-носіїв залежить від параметру JVM

jdk.virtualThreadScheduler.parallelism

Тобто ви можете зазначити свою власну кількість потоків тут, але треба розуміти, що найкраща продуктивність досягається тоді, коли виконуєтья умова типу «один поток на один CPU».

UPD: не OC відповідає за розподілення віртуальних потоків, а JVM.

Було б добре, якщо б це було правдою, але явно відбудеться ревізія архітектури фрейморків.

А так як ТредЛокал це по суті тупо синхронізована Map то і проблем не буде, тому що кожен тред, що віртуальний що платформений буде мати свої копії змінних

Так, все вірно! Але ж питання у тому, що кількість екземплярів ThreadLocals при використанні звичайних тредів обмежена фізичною кількістю ОС потоків на одни процес, а от із віртуальними тредами постане питання ефективності їх використання враховуючи майже необмежене масштабування віртуальних тредів (обмежених наявною пам’яттю).

Тобто, мережевий додаток стане «швидшим», але якщо сам додаток активно використовує ThreadLocals, то буде явне просідання по пам’яті яка є спільним ресурсом.

У коді віще є фабрика яка створює потоки із іммутабельними ThreadLocals.

А взагалі у розробці зараз знаходиться альтернатива ThreadLocal — Extent Locals. Коли JEP дійде до статусу «кандидата», я напишу статтю про них.

Я знаю, ще деякі фремворки вже працюють над впровадженням, і є навіть POC.

Враховуючи те, що стандартний інтерфейс потоків захований від розробників за абстракціями типу Futute, то перехід буде безболісним, питання, мабудь, лише в ThreadLocals — як багато фремворки використовують це сховище? Бо якщо створити ExecutorService в якому по-замовчуванню не буде ThreadLocals працювати на запис, то як сильно все зламається — питання відкрите.

Synchronize не дозволить двом Java потокам одночасний доступ до непотокобезпечного нативного коду, є багато прикладів C/C++ API типу OpenCV::VideoCapture.