On Jun 26, 2008, at 7:41 AM, Lukas Stadler wrote: > This is my current version of the callcc.patch ... working with the > callcc code the last few weeks brought up a few problems (safepoint- > safety, ...) for which I made some changes. > > * the deopt_blob isn't patched into the return pc any more because > the vframearray already exists when the resumeStack method returns > and thus the oops that it contains could be collected. the > deopt_blob is now called like a method and thus the continuation > entry point now behaves like a method entry point.
I've pushed your most recent changes. I tweaked it a bit to get it to build and run on Solaris. (My development platform is Solaris / VMware / MacBook Pro.) I also changed stackframe to stackFrame or stack_frame, as appropriate to language and context. The "smoke test" (i.e., does the widget emit puffs of smoke when power is applied?) runs as before. I rebased everything to the current build, b30. There was a puzzle with MonitorInfo structs; they grew another field (called "eliminated") because of escape analysis, and I am not sure I passed the values through correctly: Please give it a look: http://hg.openjdk.java.net/mlvm/mlvm/hotspot http://hg.openjdk.java.net/mlvm/mlvm/jdk > * (this is part of anonk.patch) I've changed line 387 of > constantPoolOop.cpp to "assert(pseudo_ok || > java_lang_String::is_instance(entry), "must be string"); " because > of a compiler warning that prohibited product builds. I pushed that separately, along with an anonk fix that sneaked into the callcc patch. Regarding your earlier comments: > * there are two copyStack methods, but the resumeStack method can > be used for both code paths! You'll have noticed that the serialization-based POC was simpler to code up, but of course the data-structure-based one has the potential to be faster (and to allow data structure reuse for related continuations). Let's make sure the extra structure pays for itself. > * the new continuation entry point in the deopt_blob is only > implemented in the x86 version - it gets the UnrollBlock via rax That's OK for now. It will have to be ported to SPARC at some point, but we're not there yet. > * I have added code to javaClasses.* for my Continuation and > Stackframe classes Right. See comment above. > * doCopyStackContext is now an intrinsic Java method that will > always be interpreted, this allows for nested doCopyStackContext calls > * I made some initial performance improvements > * I was surprised how costly it is to create the reflection method > object Maybe method handles can bail us out here. (I put a comment in to that effect.) The idea is that a method handle is to the methodOop as a Class object is to a klassOop: It's a small Java handle to the ineffable metaobject. Reflective methods are more like symbol table entries; they are intrinsically bulky. > * there are lots of things that could be cached, like oop maps, etc > * I think that it should be allowed to reuse a Continuation > object, this would save allocation time Yes; they should probably present an immutable interface also. > * I think that in the long run there should be a special deoptblob/ > UnrollBlock implementation for continuations, for performance reasons > * the return value and exception for the continuations are now > stored in UnrollBlock, I'm not sure if this is ok In general, if you do it the way deopt does, you'll be safest. Thanks for the good work! Best wishes, -- John _______________________________________________ mlvm-dev mailing list [email protected] http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
