I don't want to discourage you from contributing but... as also descripted in the Loom proposal already suggests - it's much more than just patching the Instrumenter. If you want to re-use the threads you also need to add some kind of pooling and scheduling mechanism.
On Sun, Jan 21, 2018 at 2:00 AM, Cristian Lorenzetto < cristian.lorenze...@gmail.com> wrote: > I read now Loom project is thinking to do exactly what i proposed. But when > it will be available? uhmmm i think i could require years... > I dont know , maybe i could patch the instrumenter > > 2018-01-21 1:21 GMT+01:00 Torsten Curdt <tcu...@vafer.org>: > > > This does not remove the restriction on the synchronization - that still > > exists. > > The thread could do something else during the wait - but that's another > > story. > > > > There just is not automatic suspend on wait. > > And it begs the question how such a thing would/should look like. > > > > I am not saying this isn't something that could be interesting to > > investigate - but this is just not what javaflow is. > > The current javaflow implementation is about state storing and restoring > - > > not scheduling and pooling. > > > > While you could improve thread usage by implementing thread re-use during > > wait, the big problem will still always be the synchronized code. > > So it really feels like you are trying to solve a problem from the wrong > > end. > > > > Anyway - my 2 cents. > > Take them or leave 'em ;) > > > > On Sun, Jan 21, 2018 at 12:36 AM, Cristian Lorenzetto < > > cristian.lorenze...@gmail.com> wrote: > > > > > It is absolutely not true. If a coroutine execute > > > > > > synchonized(lock){ lock.wait() } > > > > > > the lock.wait blocks the thread. Why i have to block the thread if > thread > > > can running other corotuines in the while? > > > lock.wait must supend the coroutine and resuming another coroutine > > > > > > 2018-01-21 0:23 GMT+01:00 Torsten Curdt <tcu...@vafer.org>: > > > > > > > I am sorry but I must be missing something here. > > > > > > > > The code uses synchronization blocks and mutexes to explicitly make > > sure > > > > threads don't interfere which each other. > > > > This restriction will be there because of resource sharing and the > java > > > > memory model. > > > > Instrumenting wait/notify cannot magically remove that restriction. > > > > > > > > Based on queuing theory you can move your bottleneck to your mutexes > - > > > but > > > > that's about it. > > > > > > > > > >