Am 2011-04-28 15:00, schrieb Mark Roos:
Of course I would love to see the low level infrastructure in jdk7
binaries.
Well, that would be cool, but I think the scope for JDK7 is very much
fixed by now, and it's a much too short timeframe anyway...
My thought was to use coroutines to emulate Smalltalk processes. For
this I need to convert the
machine stack to objects, inspect and manipulate them from the
Smaltalk side and then covert them
back, Does the above statement mean that this feature is going away?
No, "copy to/from stack logic" refers to internal implementation
details, it won't change any of the APIs.
Am 2011-04-28 16:33, schrieb Charles Oliver Nutter:
How would you feel about leading a JSR? :)
Yeah, right :-)
I'll talk to John about how we can approach this. He's probably the one
with the sudo access.
Man, you need to get that patch working so I can play with it again :)
JRuby 1.7 is going to be my "experimenting with Java 7 and beyond)
release, so I'm keen to get back into coro experimentation (and tailc,
if that patch could get updated too).
HotSpot has been quite the moving target lately, but I guess that most
of the big changes are over by now. So I'll see to it that it integrates
with the other patches again...
Ouch. I think coroutines must be GCable and not act as a GC root.
Well, it's actually not that simple. There needs to be some kind of test
to see if a coroutine can just be thrown away, which basically amounts
to "does the coroutine terminate immediately if I send it a
CoroutineDeath exception?". This means that a coroutine that has
finallys or catches that handle this exception needs to be kept around,
normally until the end of the thread.
On the other hand, I talked with Jim Baker (Jython) about the
potential for using "lots and lots" of coroutines, one per
(language-level, not Java-level) method invocation, to do a poor-man's
stackless language implementation. In that case we'd need as many
coroutines as there are active method invocations on the stack, which
could easily be tens of thousands. This is, again, a rather weird and
specialized case.
Yes, and to reach the level of performance required for this the
coroutine implementation would need to be much more intrusive.
* fast 1st activation (the first time a coroutine gets to run)
How much of a difference are we talking in the best and worst cases?
The first activation is currently ~100x more expensive than subsequent
switches, because some data structures need to be set up. This can
certainly be improved upon.
And I officially offer my help in making a JSR happen (as much as my
time permits, of course).
Thanks!
Am 2011-04-28 18:41, schrieb Rémi Forax:
Also because coroutine can be used to implement concurrent web server,
there is also a need for a memory model/concurrency guy.
Definitely... although I hope to get by with "well, coroutines are just
threads that decided to only get scheduled at certain points, aren't they?".
By coroutine, I mean thread sticky coroutine, thread migration can be
added later, the most important thing is to have lots of coroutines i.e
pausable/resumable task with fast micro-scheduling.
One question that remains for me is if coroutine migration should be
explicit (that how it's implemented now), or implicit...
Lukas, if you refresh your patch, we can come at the next JVM Summit in
July with a web server that use co-routine with nio/asyncio plus some
examples of yield/iterator/generator.
That would be nice ...
_______________________________________________
mlvm-dev mailing list
[email protected]
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
