Что я вижу - они делают те же корутины, только в java, при этом трогают рантайм, а это всегда больно и опасно

Да смотрел я это все, и видео с jvmls смотрел

тогда наверно понимаешь в чем отличие от корутин)

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

Что я вижу - они делают те же корутины, только в java, при этом трогают рантайм, а это всегда больно и опасно

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

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

Вот далеко не факт, там есть плюсы и минусы. И в случае такого монстра как джава я не уверен что плюсы перевешивают

С рантаймом всё как раз просто - слизывай с Go, грубо говоря. А вот JDK потом подкрутить соответственно, не нарушив святую обратную совместимость - вот это ой

Куча всего сейчас асинхронного на java хорошо работает, и отлично живет без поддержки рантайма

С рантаймом всё как раз просто - слизывай с Go, грубо говоря. А вот JDK потом подкрутить соответственно, не нарушив святую обратную совместимость - вот это ой

Что конкретно слизывать и чем это отличается от Kotlin корутин? :)

Слизывать work-stealing. Корутины - внешняя приблуда, а Loom может позволить "блокирующее" IO сделать неблокирующим, изнутри JVM. Ну т. е. на 100500 лайт-тредов JVM юзает 10 тредов ОС, и этого хватает - если упрощать

#holywarmodeon

Слизывать work-stealing. Корутины - внешняя приблуда, а Loom может позволить "блокирующее" IO сделать неблокирующим, изнутри JVM. Ну т. е. на 100500 лайт-тредов JVM юзает 10 тредов ОС, и этого хватает - если упрощать

+

Слизывать work-stealing. Корутины - внешняя приблуда, а Loom может позволить "блокирующее" IO сделать неблокирующим, изнутри JVM. Ну т. е. на 100500 лайт-тредов JVM юзает 10 тредов ОС, и этого хватает - если упрощать

Не может, иначе квазар получится

Да не получится квазар )

Слизывать work-stealing. Корутины - внешняя приблуда, а Loom может позволить "блокирующее" IO сделать неблокирующим, изнутри JVM. Ну т. е. на 100500 лайт-тредов JVM юзает 10 тредов ОС, и этого хватает - если упрощать

work-stealing давно есть в ForkJoin

Это тоже отдельная приблуда в JDK, а не кусок рантайма

Не может, иначе квазар получится

Квазар пытается добиться той же цели СНАРУЖИ JVM, хаками и костылями. Оттого и ужас

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

и легаси код с Thread.sleep

Квазар пытается добиться той же цели СНАРУЖИ JVM, хаками и костылями. Оттого и ужас

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

Не автомагически

work-stealing давно есть в ForkJoin

+

Положительное отличие Loom от корутин только в том, что можно будет избежать явного копирования контекста, то есть производительность немного улучшится. Все.

Там сама реализация корутин в loom копированием стека вызывает вопросы. А стоит ли это делать, и не лучше ли state машина

и легаси код с Thread.sleep

Пофантазируем. Thread.sleep не блокирует тред ОС, а говорит: так, я тут потуплю чутка, тред свободен, можете его спереть себе кому надо. Это и есть work-stealing. Никакой магии, очень простая идея. Дьявол, как всегда, в деталях. Как это подружится с API JDK - большой вопрос

Пофантазируем. Thread.sleep не блокирует тред ОС, а говорит: так, я тут потуплю чутка, тред свободен, можете его спереть себе кому надо. Это и есть work-stealing. Никакой магии, очень простая идея. Дьявол, как всегда, в деталях. Как это подружится с API JDK - большой вопрос

yield()

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

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

yield()

Дополнительная сущность. Можно без неё обойтись

она просто у тебя неявно будет, как и suspend неявный

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

оракл уже ж изьявил желание сделать такое

она просто у тебя неявно будет, как и suspend неявный

Да. И работать будет с тем же JDBC, без необходимости переписывать JDBC на неблокирующее API

Ну т. е. грубо говоря, блокирующий код перестаёт быть "не делай так никогда!!!". Потому что блокируются не треды ОС (дорогие), а абстракция JVM (относительно дешёвая)

Да. И работать будет с тем же JDBC, без необходимости переписывать JDBC на неблокирующее API

Вот это я вообще не могу представить, loom будет таким умным что корневые api магически подменит? и кто-то надеится что это будет реально работать в 80% случаев?

Да. И работать будет с тем же JDBC, без необходимости переписывать JDBC на неблокирующее API

апи в любом случае поменяется

она просто у тебя неявно будет, как и suspend неявный

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

Ну т. е. грубо говоря, блокирующий код перестаёт быть "не делай так никогда!!!". Потому что блокируются не треды ОС (дорогие), а абстракция JVM (относительно дешёвая)

Звучит красиво, но как я говорю - они попробуют, поймут что это нереалисточно в условиях реального мира и багажа джавы и не будут затаскивать такую магию

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

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

Звучит красиво, но как я говорю - они попробуют, поймут что это нереалисточно в условиях реального мира и багажа джавы и не будут затаскивать такую магию

Там выше скрин приводили, пацаны осознают, на что замахнулись и сколько геморроя их ждёт

Звучит красиво, но как я говорю - они попробуют, поймут что это нереалисточно в условиях реального мира и багажа джавы и не будут затаскивать такую магию

ну как сказали, это пока слишком ранние прототипы и года через 3 только реализуют и попробуют зарелизить, а когда это начнут юзать так вообще все 5 лет пройдут

Ладно, попробуем с другой стороны. Почему блокировки тредов - плохо? Или плодить 100500 тредов на каждый чих - плохо?

ну как сказали, это пока слишком ранние прототипы и года через 3 только реализуют и попробуют зарелизить, а когда это начнут юзать так вообще все 5 лет пройдут

А там и Kotlin 3.0 релизнется?

Ладно, попробуем с другой стороны. Почему блокировки тредов - плохо? Или плодить 100500 тредов на каждый чих - плохо?

тем что нужно держать тредов больше чем CPU?

тем что нужно держать тредов больше чем CPU?

И? ОС для того и нужна, чтобы исполнять 100 тредов на одном ядре CPU. Глубже.

Ладно, попробуем с другой стороны. Почему блокировки тредов - плохо? Или плодить 100500 тредов на каждый чих - плохо?

потому что заблокированный тред - это заблокированный тред:)

Я не троллинга ради спросил

Ладно, попробуем с другой стороны. Почему блокировки тредов - плохо? Или плодить 100500 тредов на каждый чих - плохо?

ну context switching. с корутинами/loom мы делаем кооперативную многозадчность, в текущем железе есть один способ это сделать, вопрос в подходе. подход loom пока копипастить стеки, делать это в рантайме, подход корутин делать стейт машину.

И? ОС для того и нужна, чтобы исполнять 100 тредов на одном ядре CPU. Глубже.

ты сделал 100500 тредов, тебе каждое переключение треда, это смена контекста, сброс кешов и при этом каждый тред занимает еще с мегабайт памяти

Я не троллинга ради спросил

1. Создание треда - дорогая операция 2. Создавать тредов больше, чем позволяет окружение - просто накладно с точки зрения производительности 3. Любой простаивающий тред - это ресурс, который ты не можешь использовать

Это верно, если у нас тред JVM == тред ОС

Это верно, если у нас тред JVM == тред ОС

Так, а файбер в loom будет выполняться на магическом лайт треде, да? Совсем не как корутины?)

Это верно, если у нас тред JVM == тред ОС

Ну я в своих пунктах потому и не упомянул ОС

Суммируя вышесказанное - корутины не болеют многими проблемами тредов потому что это и не треды:) во всяком случае, так это понимаю я

Корутины есть только в котлин, ребята. JDK ими воспользоваться не может

Корутины есть только в котлин, ребята. JDK ими воспользоваться не может

это как?)

Корутины есть только в котлин, ребята. JDK ими воспользоваться не может

почему?

Корутины есть только в котлин, ребята. JDK ими воспользоваться не может

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

почему?

Ну вот пишет Doug Lea новый java.util.concurrent.SuperPuperClass, и такой: о, а дай-ка я из него корутины заюзаю

Ну вот пишет Doug Lea новый java.util.concurrent.SuperPuperClass, и такой: о, а дай-ка я из него корутины заюзаю

Даг Ли напишет на колбеках, а мы обернем в наши классные корутины. И всем хорошо

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

Отвечу вопросом на вопрос. Loom на что нацелен - на перепиливание java.util.Thread (на самом деле глубже, перепиливание кода jvm)? Или на предоставление ещё одной абстракции сбоку от java.util.Thread?

Даг Ли напишет на колбеках, а мы обернем в наши классные корутины. И всем хорошо

На колбеках. На корутинах он не может. Я об этом.

Отвечу вопросом на вопрос. Loom на что нацелен - на перепиливание java.util.Thread (на самом деле глубже, перепиливание кода jvm)? Или на предоставление ещё одной абстракции сбоку от java.util.Thread?

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

На колбеках. На корутинах он не может. Я об этом.

а разница..?)

Что конкретно слизывать и чем это отличается от Kotlin корутин? :)

Стек не будет размазан по хипу. Разве так не лучше?

Отвечу вопросом на вопрос. Loom на что нацелен - на перепиливание java.util.Thread (на самом деле глубже, перепиливание кода jvm)? Или на предоставление ещё одной абстракции сбоку от java.util.Thread?

будет же отдельная абстракция

Стек не будет размазан по хипу. Разве так не лучше?

В Loom стек будет куском копироваться в хип. А в корутинах и стек не хранится в общем-то. Только состояние стейт машины

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

Ладно, раскрою карты: его нет :) С корутинами не работал, про Loon сегодня услышал впервые и предположил, что чуваки целят поменять реализацию Thread. Из этой иллюзии понимания и исхожу

Менять реализацию Thread низя. Все поламается.

В Loom стек будет куском копироваться в хип. А в корутинах и стек не хранится в общем-то. Только состояние стейт машины

Ну состояние стейт-машины это считай и есть stack frame. И они лежат в хипе не одним куском, а разными объектами. Что-то мне подсказывает, что это влияет на производительность отрицательно.

В Loom стек будет куском копироваться в хип. А в корутинах и стек не хранится в общем-то. Только состояние стейт машины

Я, если что, не про ту реализацию Loom, которая работает практически как сейчас корутины (прототип же), а про то, что будет, если сделать нормально.

Ну состояние стейт-машины это считай и есть stack frame. И они лежат в хипе не одним куском, а разными объектами. Что-то мне подсказывает, что это влияет на производительность отрицательно.

Но состояние это один int, а стек может быть большим. В общем это тяжелый вопрос, нужно тестить, для этого и делают прототип. И что лучше, сложно сказать, в go копируют стек, но там какие-то хитрые оптимизации чтобы быстро работало. Можно ли оптимизровать это в jvm - для меня вопрос, и если например нет - то скорее всего хуже работать будет.

Ладно, раскрою карты: его нет :) С корутинами не работал, про Loon сегодня услышал впервые и предположил, что чуваки целят поменять реализацию Thread. Из этой иллюзии понимания и исхожу

Не кажется как минимум некорректным спорить, не имея понимания предмета?

Вообще, спор довольно пустой. До Loom мы не факт, что доживем. Это еще лет 10 будет в разработке.

на OracleOne его активно пиарили)

Не кажется как минимум некорректным спорить, не имея понимания предмета?

Ну, это один из способов такое понимание получить. Другое дело, что надо было сразу озвучить, что знаний нет, есть предположения

на OracleOne его активно пиарили)

Уже лет 5 как.

Ну, это один из способов такое понимание получить. Другое дело, что надо было сразу озвучить, что знаний нет, есть предположения

Очень странно спорить, не зная предмета, именно спорить. Задавать вопросы и уточнять - ради бога.

Не кажется как минимум некорректным спорить, не имея понимания предмета?

А, так вы спорите? А предмет спора какой тогда? Мне просто показалось, что тут народ пытается понять, о чём вообще речь.

А, так вы спорите? А предмет спора какой тогда? Мне просто показалось, что тут народ пытается понять, о чём вообще речь.

Я нет, я вообще мимокрокодил.

Так а кто и о чём спорит?

Предмет спора какой? Какие есть точки зрения? Кто их высказал? Какие аргументы? Я ничего этого пока в обсуждении не увидел.

Уже лет 5 как.

в последние пару лет когда начали активно форсить асинхронные апи, реактивщину и тд, уже многое под это адаптировалось.. а они только вот прототипы делают, а через 5 лет если они прийдут и скажут "чуваки, мы вот сделали классную штуку", то она уже никому и не будет нужна в принципе, даже котлину

как всегда тут какой-то срачь...

в последние пару лет когда начали активно форсить асинхронные апи, реактивщину и тд, уже многое под это адаптировалось.. а они только вот прототипы делают, а через 5 лет если они прийдут и скажут "чуваки, мы вот сделали классную штуку", то она уже никому и не будет нужна в принципе, даже котлину

Ну я про тоже. Кстати, я так понял, кто запуск Kotlin сильно подстегнул разработку JVM в этом смысле.

А еще сейчас почти готов Graal. Он с человеческим языком внутри, так что я думаю, что это откроет простор для экспериментов.

Предмет спора какой? Какие есть точки зрения? Кто их высказал? Какие аргументы? Я ничего этого пока в обсуждении не увидел.

Как я понял, суть спора - нужен ли Loom, особенно тем, кто пишет на котлине. Точки зрения: - да - нет - какая разница, если он выйдет лет через 5

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

Как я понял, суть спора - нужен ли Loom, особенно тем, кто пишет на котлине. Точки зрения: - да - нет - какая разница, если он выйдет лет через 5

Это хорошо если через 5.

У нас появился мета чат. Это такой чат чтобы обсуждать чат. @kotlin_meta

У нас появился мета чат. Это такой чат чтобы обсуждать чат. @kotlin_meta

Совершили метасистемный переход значитЪ

У нас появился мета чат. Это такой чат чтобы обсуждать чат. @kotlin_meta

We need to go deeper.

-> @kotlin_meta please

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

и то, мест в коде где я явно вызываю такое всего несколько. в основном это спрятано под обертками возможно диспатчеры станут более умными и смогут сами переводить потоки в wait состоянии в IO контекст ну и библиотечки активно начинают поддерживать async api, чтобы как-то жить, так что эти костыли с IO не на долго

Очень странно спорить, не зная предмета, именно спорить. Задавать вопросы и уточнять - ради бога.

У меня не было намерения именно спорить. Я специально оговорки делал "я так понимаю, что loom - это go-шный work stealing"

и то, мест в коде где я явно вызываю такое всего несколько. в основном это спрятано под обертками возможно диспатчеры станут более умными и смогут сами переводить потоки в wait состоянии в IO контекст ну и библиотечки активно начинают поддерживать async api, чтобы как-то жить, так что эти костыли с IO не на долго

Ненадолго, да... как java.util.Date )

Если по предмету спора, то рантайм поддержка сопрограмм в JVM (fiber) нужна всем языкам, которые компилируются в JVM байт код. Точно так же, как нужна поддержка в JVM оптимизации хвостовых вызовов. Без этого, как первое, так и второе реализуется в Kotlin хитрой генерацией байт кода, которая при этом не для всех случаев сможет нормально работать. Для хвостовых вызовов не работает при взаимной рекурсии, для сопрограмм не вникал, но думаю тоже будут всякие особые случаи, когда не получится на генерации байт кода обойти ограничения JVM.