new callcc.patch

[John Rose]

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