Re: Coro patch
Seconds after I email...A DISCOVERY... It seems like invokedynamic is causing headaches for coro. Here's the numbers with coro fibers and JRuby's invokedynamic support turned *off*: 100 fibers / 1000 passes: 0.076000 0.00 0.076000 ( 0.077000) 100 fibers / 1000 passes: 0.076000 0.00 0.076000 ( 0.076000) 100 fibers / 1000 passes: 0.105000 0.00 0.105000 ( 0.105000) 100 fibers / 1000 passes: 0.07 0.00 0.07 ( 0.07) Perhaps the fix you (Lukas) made to get coro + indy working together has impacted performance? Awesome, awesome, awesome to see the above perf numbers...regardless! - Charlie On Wed, Nov 30, 2011 at 1:46 AM, Charles Oliver Nutter wrote: > Ok, good news and not as good news! > > The good news is that coro seems to be working in the latest > openjdk-osx-build, and it definitely improves JRuby's coroutine > performance! > > For running bench_fiber_ring with 100 fibers passing 1000 messages, > here's numbers for the threaded impl: > > 100 fibers / 1000 passes: 1.07 0.00 1.07 ( 1.071000) > 100 fibers / 1000 passes: 1.07 0.00 1.07 ( 1.07) > 100 fibers / 1000 passes: 1.092000 0.00 1.092000 ( 1.092000) > 100 fibers / 1000 passes: 1.077000 0.00 1.077000 ( 1.077000) > > And with the coro impl: > > 100 fibers / 1000 passes: 0.215000 0.00 0.215000 ( 0.215000) > 100 fibers / 1000 passes: 0.217000 0.00 0.217000 ( 0.217000) > 100 fibers / 1000 passes: 0.212000 0.00 0.212000 ( 0.212000) > 100 fibers / 1000 passes: 0.216000 0.00 0.216000 ( 0.215000) > > Hooray! > > Now for the not-as-good news... > > Here's Ruby 1.9.3 on the same benchmark: > > 100 fibers / 1000 passes: 0.16 0.00 0.16 ( 0.155562) > 100 fibers / 1000 passes: 0.15 0.00 0.15 ( 0.156581) > 100 fibers / 1000 passes: 0.16 0.00 0.16 ( 0.155351) > 100 fibers / 1000 passes: 0.15 0.00 0.15 ( 0.156776) > > Now even getting close to 1.9.3 is really awesome, but I'm wondering > if either I'm doing something wrong (maybe broke something in the > coro-based fiber impl?) or if something regressed in coro, because > Lukas's blog post showed JRuby + coro performing significantly > *better* than C Ruby. > > This is also a bit tricky to profile...since call stacks are jumping > around a bit :) A dumb sampled profile doesn't show much other than > Ruby code being hit heavily...which I'd expect. > > Lukas: Are you able to reproduce these numbers with JRuby master and > bench/bench_fiber_ring.rb? Here's the command line I'm using: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 20 100 1000 > > - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Coro patch
Ok, good news and not as good news! The good news is that coro seems to be working in the latest openjdk-osx-build, and it definitely improves JRuby's coroutine performance! For running bench_fiber_ring with 100 fibers passing 1000 messages, here's numbers for the threaded impl: 100 fibers / 1000 passes: 1.07 0.00 1.07 ( 1.071000) 100 fibers / 1000 passes: 1.07 0.00 1.07 ( 1.07) 100 fibers / 1000 passes: 1.092000 0.00 1.092000 ( 1.092000) 100 fibers / 1000 passes: 1.077000 0.00 1.077000 ( 1.077000) And with the coro impl: 100 fibers / 1000 passes: 0.215000 0.00 0.215000 ( 0.215000) 100 fibers / 1000 passes: 0.217000 0.00 0.217000 ( 0.217000) 100 fibers / 1000 passes: 0.212000 0.00 0.212000 ( 0.212000) 100 fibers / 1000 passes: 0.216000 0.00 0.216000 ( 0.215000) Hooray! Now for the not-as-good news... Here's Ruby 1.9.3 on the same benchmark: 100 fibers / 1000 passes: 0.16 0.00 0.16 ( 0.155562) 100 fibers / 1000 passes: 0.15 0.00 0.15 ( 0.156581) 100 fibers / 1000 passes: 0.16 0.00 0.16 ( 0.155351) 100 fibers / 1000 passes: 0.15 0.00 0.15 ( 0.156776) Now even getting close to 1.9.3 is really awesome, but I'm wondering if either I'm doing something wrong (maybe broke something in the coro-based fiber impl?) or if something regressed in coro, because Lukas's blog post showed JRuby + coro performing significantly *better* than C Ruby. This is also a bit tricky to profile...since call stacks are jumping around a bit :) A dumb sampled profile doesn't show much other than Ruby code being hit heavily...which I'd expect. Lukas: Are you able to reproduce these numbers with JRuby master and bench/bench_fiber_ring.rb? Here's the command line I'm using: jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 20 100 1000 - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
tags & co
Hi to all, When building OpenJDK 8 yesterday, I could see in hg logs : Changes 7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE Summary: Fixed several EA issues with Connection Graph construction. Reviewed-by: never, twisti (detail / hgweb) coro: fix for stack walking displaced ricochet frames (detail / hgweb) Added tag jdk8-b14 for changeset 23aa7f2c80a2 (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Merge (detail / hgweb) Added tag jdk8-b13 for changeset 26fb81a1e9ce (detail / hgweb) Added tag jdk8-b12 for changeset 8e2104d565ba (detail / hgweb) BTW, when I goes into sources directory and use hg tags, I get : tip 374:9cb255745863 qtip 374:9cb255745863 qbase374:9cb255745863 jdk7-b147-to-bsd-port.patch 374:9cb255745863 jdk8-b11 372:1defbc57940a jdk8-b10 371:a6c4c248e8fa jdk8-b09 370:8adb70647b5a jdk8-b08 369:fb1bc13260d7 jdk8-b07 363:0db7ae9f2b10 If I goes into jdk subdir, I get hg tags reports : tip 4749:8eea3d274bfd qtip4749:8eea3d274bfd coro.patch 4749:8eea3d274bfd anonk.patch 4748:38876cc39669 continuation.patch 4747:c99046535b7c meth-experiment.patch 4746:d491995b281a meth.patch 4745:92efb3787399 cval-tune-7030453.patch 4744:0fc880c23c30 meth-acc-7077803.patch 4743:3ed82c30d87c qbase 4742:93e37b71947e jdk7-b147-to-bsd-port.patch 4742:93e37b71947e jdk8-b144729:99632935785e jdk8-b134673:4cb2e8679b27 jdk8-b124663:09fd2067f715 Question, should I get tags info from jdk subdir to get the correct tag number ? Cheers ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Coro patch
> Awesome, thanks Lukas! > > Hopefully when the next openjdk-osx-build runs, it will pick up these > changes, and we'll have a working coro impl on OS X too :) Oops, forgot to tweet about it yesterday. http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-2029-release.dmg Cheers ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Coro patch
Awesome, thanks Lukas! Hopefully when the next openjdk-osx-build runs, it will pick up these changes, and we'll have a working coro impl on OS X too :) - Charlie On Tue, Nov 29, 2011 at 6:58 AM, Lukas Stadler wrote: > Uh, sorry for the long wait... > That was another problem that occurs with invokedynamic, in particular with > ricochet frames. > I fixed it, pushed the changes and uploaded a new binary to > http://ssw.jku.at/General/Staff/LS/coro/. > > - Lukas > > > On 2011-11-07 00:18, Charles Oliver Nutter wrote: > > Ok, bug report time! :) > > It looks like it's crashing again once Hotspot JITs. > > This works: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 100 100 > > But this doesn't: > > jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 1000 100 > > Here's the console output, and I've attached the log. > > # To suppress the following error report, specify this argument > # after -XX: or in .hotspotrc: SuppressErrorAt=/frame_x86.cpp:312 > # > # A fatal error has been detected by the Java Runtime Environment: > # > # Internal Error > (/Users/henri/Documents/jenkins/data/jobs/openjdk-1.8-bsdport-x86_64/workspace/sources/hotspot/src/cpu/x86/vm/frame_x86.cpp:312), > pid=21511, tid=4341268480 > # assert(sp() <= result + _displacement) failed: monitor end should > be above the stack pointer > # > # JRE version: 8.0 > # Java VM: OpenJDK 64-Bit Server VM (23.0-b03-fastdebug mixed mode > bsd-amd64 compressed oops) > # Failed to write core dump. Core dumps have been disabled. To enable > core dumping, try "ulimit -c unlimited" before starting Java again > # > # An error report file with more information is saved as: > # /Users/headius/projects/jruby/hs_err_pid21511.log > # > # If you would like to submit a bug report, please visit: > # http://bugreport.sun.com/bugreport/crash.jsp > # > Current thread is 4341268480 > Dumping core ... > Abort trap > > - Charlie > > On Sun, Nov 6, 2011 at 6:35 PM, Henri Gomez wrote: > > Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build > > 2011/11/6 Henri Gomez : > > Le 6 nov. 2011 à 22:12, Henri Gomez a écrit : > > Hi to all, > > I'm looking for Coro patch by Lukas Stadler, any body knows where I can find > it ? > > More on this, I found patch here > (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering > if it's allready applied to trunk or in some patch area ? > > Thanks for your help/advices > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > > > > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
Am 29.11.2011 23:34, schrieb Thomas Wuerthinger: > On 11/29/11 11:22 PM, Jochen Theodorou wrote: >> Am 29.11.2011 22:32, schrieb Mark Roos: >> [...] >>> I just finished a paper (link below) on JVM startup time which states >>> that for small programs its around >>> 70ms. So I assume there is some other startup time you are trying to >>> improve? Or is the >>> paper not applicable to the launching of a new process as you describe it? >> For the JVM itself that might be true, but in case of for example Groovy >> there is a lot if init work to be done before the first program can be >> executed. And this takes time. >> >> bye Jochen > What kind of initialization work is this? Could the result of that work > be cached? we have to setup the initial meta class system, which requires to use reflection to inspect some classes and other work. Yes, this could be cached, if we would know how. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
On Tue, Nov 29, 2011 at 4:34 PM, Thomas Wuerthinger wrote: > What kind of initialization work is this? Could the result of that work > be cached? I can describe the work done in JRuby's boot. We have managed to get JRuby's basic runtime to start up pretty fast; about 0.3 to 0.5s on my high-end MBP. However on other systems, especially on 64-bit Linux, startup time is still quite a bit slower. The Apple JDK does an amazing job of speeding startup that no other builds seem to have matched yet. JRuby's base init involves: * Constructing metaclasses for all the core Ruby classes like String, Array, etc. It's difficult or impossible to cache this because they are essentially key/value tables of pointers to methods...in our case, thousands of tiny classes that subclass DynamicMethod. * Initializing native bindings for POSIX features. Loading the libffi binding dynamically and programmatically wiring up all the functions we use takes a bit of startup time. * Loading additional .rb sources from classloader resources. Parts of JRuby (more and more) are implemented in Ruby; as a result, we have to load a bunch of Ruby code on boot. The bigger part of startup is loading all the third-party libraries that a user might need in their app. Those sources need to be parsed every time, turned into an AST, and partially executed to boot. All the code that does parsing and interpretation is cold initially, and so we have slow startup no matter what we do. We have experimented with serializing the parse tree or precompiling to bytecode, but neither case was actually faster than our parser. If the JVM had the ability to fork, users could potentially boot a baseline application image and then fork instances from that to run iterative tests, etc, rather than having to re-boot the entire runtime and application's dependencies every time. I'm also looking into the possibility of doing this on Dalvik; we could keep a running JRuby image in memory and then fork off that for JRuby-based applications, reducing startup time significantly. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
On 11/29/11 11:22 PM, Jochen Theodorou wrote: > Am 29.11.2011 22:32, schrieb Mark Roos: > [...] >> I just finished a paper (link below) on JVM startup time which states >> that for small programs its around >> 70ms. So I assume there is some other startup time you are trying to >> improve? Or is the >> paper not applicable to the launching of a new process as you describe it? > For the JVM itself that might be true, but in case of for example Groovy > there is a lot if init work to be done before the first program can be > executed. And this takes time. > > bye Jochen What kind of initialization work is this? Could the result of that work be cached? - thomas ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
Am 29.11.2011 22:32, schrieb Mark Roos: [...] > I just finished a paper (link below) on JVM startup time which states > that for small programs its around > 70ms. So I assume there is some other startup time you are trying to > improve? Or is the > paper not applicable to the launching of a new process as you describe it? For the JVM itself that might be true, but in case of for example Groovy there is a lot if init work to be done before the first program can be executed. And this takes time. bye Jochen -- Jochen "blackdrag" Theodorou - Groovy Project Tech Lead blog: http://blackdragsview.blogspot.com/ german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
On Tue, Nov 29, 2011 at 18:32, Mark Roos wrote: > I just finished a paper (link below) on JVM startup time which states that > for small programs its around > 70ms I don´t know about your paper, but on my single-core Atom netbook with 1.6 Ghz CPU and 2 Gigs of RAM running WinXP SP3 and JRE 7.0, starting Jython takes a whopping 10-20 seconds... even more the first time I think. But I admit that might be more an issue with Jython than the JVM... Plus, if start-up time of small apps wasn´t an issue Nailgun wouldn´t even be needed. :) FC -- "The purpose of computing is insight, not numbers." Richard Hamming - http://en.wikipedia.org/wiki/Hamming_code ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Process-level fork on OpenJDK...is it madness?
Interesting. I guess if you could save that state to disk and reload it then you would have the equivalent of the Smalltalk image concept. Although it seems like this would be hard to be op sys neutral. It also seems it would help the warmup issue with Hotspot by preloadiing its counters etc. I just finished a paper (link below) on JVM startup time which states that for small programs its around 70ms. So I assume there is some other startup time you are trying to improve? Or is the paper not applicable to the launching of a new process as you describe it? I would think that someway to serialize application state would be more interesting than an complete clone of java memory and the following restart. As I recall from the Smalltalk image code the big issue was not the threads but was with all of the op sys handles that need to be reconstituted. I look forward to the responses mark www.mii.lt/olympiads_in_informatics/pdf/INFOL073.pdf___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
JRuby invokedynamic updates for November
Hello friends! Just updating you on the status of JRuby + invokedynamic, for those of you following along. About halfway through this month I did another pass at getting tests passing with invokedynamic enabled, and finally turned on all uses (at the time) of indy in JRuby! Hooray! Last week, I finally enabled Ruby to Java dispatch via invokedynamic for single-arity methods as well. The performance on those calls appears to be about double what it was before...reflection is a harsh mistress. Last night, I added an experimental change to use invokedynamic for looking up Ruby instance variables. Ruby ivars are basically like a Map on every object, so we use various techniques to avoid storing an entire map. My hope is that an indy lookup path will be faster than the non-indy path...but so far, they're about equal. I have not enabled this on master, but it can be enabled by passing -Xinvokedynamic.cache.ivars=true to JRuby or -Djruby.invokedynamic.cache.ivars=true passed to Java. Invokedynamic is being used for the following: * Method dispatches from Ruby to Ruby with fixed-arity target methods that do not require heap frames * Method dispatches from Ruby to Java with fixed-arity target methods * Loads of literals and lazily-allocated runtime constructs * Constant lookups * Math and boolean operations where the right operand is a literal integer or float have special treatment Things are looking very good. Also recently, I modified how JRuby prints out configuration properties. All properties for invokedynamic should now be properly displayed by passing --properties to JRuby. Upcoming work includes getting Ruby methods with variable arity and heap frames to use invokedynamic, as well as Java methods with variable arity. Have fun! - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
hg: mlvm/mlvm/hotspot: coro: fix for stack walking displaced ricochet frames
Changeset: a798eba1f10a Author:Lukas Stadler Date: 2011-11-29 13:57 +0100 URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a798eba1f10a coro: fix for stack walking displaced ricochet frames ! coro.patch ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Coro patch
Uh, sorry for the long wait... That was another problem that occurs with invokedynamic, in particular with ricochet frames. I fixed it, pushed the changes and uploaded a new binary to http://ssw.jku.at/General/Staff/LS/coro/. - Lukas On 2011-11-07 00:18, Charles Oliver Nutter wrote: Ok, bug report time! :) It looks like it's crashing again once Hotspot JITs. This works: jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 100 100 But this doesn't: jruby --1.9 -Xfiber.coroutines=true bench/bench_fiber_ring.rb 10 1000 100 Here's the console output, and I've attached the log. # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/frame_x86.cpp:312 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (/Users/henri/Documents/jenkins/data/jobs/openjdk-1.8-bsdport-x86_64/workspace/sources/hotspot/src/cpu/x86/vm/frame_x86.cpp:312), pid=21511, tid=4341268480 # assert(sp()<= result + _displacement) failed: monitor end should be above the stack pointer # # JRE version: 8.0 # Java VM: OpenJDK 64-Bit Server VM (23.0-b03-fastdebug mixed mode bsd-amd64 compressed oops) # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again # # An error report file with more information is saved as: # /Users/headius/projects/jruby/hs_err_pid21511.log # # If you would like to submit a bug report, please visit: # http://bugreport.sun.com/bugreport/crash.jsp # Current thread is 4341268480 Dumping core ... Abort trap - Charlie On Sun, Nov 6, 2011 at 6:35 PM, Henri Gomez wrote: Ok, I get them and coro is included in OpenJDK 8 from openjdk-osx-build 2011/11/6 Henri Gomez: Le 6 nov. 2011 à 22:12, Henri Gomez a écrit : Hi to all, I'm looking for Coro patch by Lukas Stadler, any body knows where I can find it ? More on this, I found patch here (http://hg.openjdk.java.net/mlvm/mlvm/jdk/rev/ca450b9f8b56), but wondering if it's allready applied to trunk or in some patch area ? Thanks for your help/advices ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Process-level fork on OpenJDK...is it madness?
Just to make it clear here, I'm editing the subject...my interest is in "process forking", not "open source forking" :) - Charlie On Tue, Nov 29, 2011 at 2:12 AM, Charles Oliver Nutter wrote: > Ok, hypothetical situation. What if a patch were crafted for OpenJDK > that could make it possible to safely fork(2) the JVM process. What > would it look like? > > Obviously VM-critical threads would have to be restarted. Such a thing > is certainly possible; the Rubinius VM maintains background threads > for JIT requests, etc, and before forking forces them to a safe point. > After forking, they are resumed at with their original state. Could > this be done for the OpenJDK worker threads? > > On a JVM I have just started, running jruby -e "sleep", I see the > following non-userland threads: > > * DispatchQueue_1: com.apple.main-thread (serial) > > This is presumably the thread started up to handle Cocoa events. I > assume there would be a way to re-start it on the other side. > > * The main thread > > This is the actual JVM "main" thread, and on my trace the stack tops > out in the "sleep" monitor. We can assume this is the thread we want > to survive forking. > > * Eight GC threads > > Possible to force them to a safe point and re-launch on the other > side? The stacks they're sitting on are not very deep... > > * An unidentifier thread > > It looks like this...I'm not sure what this one is doing: > > 2597 java_start(Thread*) > 2597 VMThread::run() > 2597 VMThread::loop() > 2597 Monitor::wait(bool, long, bool) > 2597 Monitor::IWait(Thread*, long long) > 2597 os::PlatformEvent::park(long long) > 2597 _pthread_cond_wait > 2597 __semwait_signal > > * Java: Reference Handler > > The java.lang.ref handler. Presumably this could also be restarted, > since normally it sits there doing nothing...just waiting for work. > > * Java: Finalizer > > Again, a thread that normally does no work and could presumably be restarted. > > * Java: Signal Dispatcher > > This is certainly trickier, but I assume the same signal handling > logic that works in the parent could be restarted in the child without > a great deal of effort. > > * Two Java: C2 CompilerThread0 > > Normally not doing anything; presumably could be restarted. > > * Java: Service Thread > * Another unknown thread > > These looks similar to the unknown thread above. I am guessing these > threads are more OS X-specific stuff... > > ... > > So, most of the threads in question seem like they could be paused, > saved off in some way, and restarted on the other side. Of course it's > not that simple...I assume there's on-stack state that would need to > be translated and bootstrapped in the child. I also assume the JVM has > some intimate knowledge of memory layout that might go all wacky in > the presence of fork. But is something like this feasible in theory? > > I ask because one of the biggest complaints from JRuby users is the > inability to fork...not just for doing fork+exec-style process > launching, but for initializing some state and preforking children. > > And JRuby's not alone. Dalvik supports forking, which is a large part > of why it's able to boot small Java applications so darn quickly; the > base Dalvik process has already initialized a bunch of VM and Android > state, and the foked child just boots application-specific logic. > > I'm interested in finding a way to make this happen. > > - Charlie > ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Forkable OpenJDK...is it madness?
On Tue, Nov 29, 2011 at 2:17 AM, Fernando Cassia wrote: > It exists, and it´s a work-around, but it works very well... nailgun. ;-) > > http://www.martiansoftware.com/nailgun/ Nailgun is a fairly limited solution that isn't really comparable to fork: * There's no process isolation; one bad "nail" can seal the coffin. * There's no simple way to do prefork-style initialization; each "nail" must explicitly share the *same* in-memory resources, or initialize its own * Signal handling does not work properly across the nailgun process wire (could be improved, but it's still emulating signal handling atop a wire protocol) JRuby already ships with Nailgun, and we recommend it as a possible for solution to improve startup of quick tasks, but it's no fork. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: Forkable OpenJDK...is it madness?
On Tue, Nov 29, 2011 at 05:12, Charles Oliver Nutter wrote: > And JRuby's not alone. Dalvik supports forking, which is a large part > of why it's able to boot small Java applications so darn quickly; the > base Dalvik process has already initialized a bunch of VM and Android > state, and the foked child just boots application-specific logic. > > I'm interested in finding a way to make this happen. > > - Charlie It exists, and it´s a work-around, but it works very well... nailgun. ;-) http://www.martiansoftware.com/nailgun/ FC -- "The purpose of computing is insight, not numbers." Richard Hamming - http://en.wikipedia.org/wiki/Hamming_code ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Forkable OpenJDK...is it madness?
Ok, hypothetical situation. What if a patch were crafted for OpenJDK that could make it possible to safely fork(2) the JVM process. What would it look like? Obviously VM-critical threads would have to be restarted. Such a thing is certainly possible; the Rubinius VM maintains background threads for JIT requests, etc, and before forking forces them to a safe point. After forking, they are resumed at with their original state. Could this be done for the OpenJDK worker threads? On a JVM I have just started, running jruby -e "sleep", I see the following non-userland threads: * DispatchQueue_1: com.apple.main-thread (serial) This is presumably the thread started up to handle Cocoa events. I assume there would be a way to re-start it on the other side. * The main thread This is the actual JVM "main" thread, and on my trace the stack tops out in the "sleep" monitor. We can assume this is the thread we want to survive forking. * Eight GC threads Possible to force them to a safe point and re-launch on the other side? The stacks they're sitting on are not very deep... * An unidentifier thread It looks like this...I'm not sure what this one is doing: 2597 java_start(Thread*) 2597 VMThread::run() 2597 VMThread::loop() 2597 Monitor::wait(bool, long, bool) 2597 Monitor::IWait(Thread*, long long) 2597 os::PlatformEvent::park(long long) 2597 _pthread_cond_wait 2597 __semwait_signal * Java: Reference Handler The java.lang.ref handler. Presumably this could also be restarted, since normally it sits there doing nothing...just waiting for work. * Java: Finalizer Again, a thread that normally does no work and could presumably be restarted. * Java: Signal Dispatcher This is certainly trickier, but I assume the same signal handling logic that works in the parent could be restarted in the child without a great deal of effort. * Two Java: C2 CompilerThread0 Normally not doing anything; presumably could be restarted. * Java: Service Thread * Another unknown thread These looks similar to the unknown thread above. I am guessing these threads are more OS X-specific stuff... ... So, most of the threads in question seem like they could be paused, saved off in some way, and restarted on the other side. Of course it's not that simple...I assume there's on-stack state that would need to be translated and bootstrapped in the child. I also assume the JVM has some intimate knowledge of memory layout that might go all wacky in the presence of fork. But is something like this feasible in theory? I ask because one of the biggest complaints from JRuby users is the inability to fork...not just for doing fork+exec-style process launching, but for initializing some state and preforking children. And JRuby's not alone. Dalvik supports forking, which is a large part of why it's able to boot small Java applications so darn quickly; the base Dalvik process has already initialized a bunch of VM and Android state, and the foked child just boots application-specific logic. I'm interested in finding a way to make this happen. - Charlie ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
