[M3commit] how to switch userthreads on/off

[jay.krell at cornell.edu]

I've also been forgetting that I upset the apple cart by merging the  
two thread locals into one. Pusheframe did not otherwise depend on  
heap allocation. Still I think current is good.

  - Jay (phone)

On Apr 28, 2009, at 5:06 PM, Jay <jay.krell at cornell.edu> wrote:

>
>> I realize maybe there is a strong counteropinion, like, whatever
>> inefficiences are >implied by dynamic linking are to be "fought"
>> against with aggressive/creative/even fragile optimization  
>> techniques.
>
>
> I realize I argue for optimizing PushEFrame and for deoptimizing  
> e.g. lock.
> PushEFrame is presumably more common...except that it probably  
> occurs most often with lock? I don't know, I have no numbers.
>
>
> I'm not sure yet what to do here.
> Swapping .so files might or might not work.
> If it does, that's a step but doesn't enable everything.
>
>
> For example when I just switch compilation back and forth without  
> "clean", I get errors about types missing. Maybe that'll occur at  
> runtime, maybe not? Maybe these are different? Depends somewhat on  
> what "reveal" does?
> Maybe Thread.T/Mutex/Condition should be ADDRESS and never revealed,  
> but loopholed to escape these problems?? ("These problems" are  
> partly that I don't fully understand the Modula-3 object model, e.g.  
> what does "reveal" do, at a low level? What does "brand" do, at a  
> low level? I looked into it some and brand doesn't seem to affect  
> objects at all, only out of band typeinfo.)
>
>
> Maybe just leave it as an option in m3core's m3makefile and people  
> can twiddle it if they want and rebuild the entire system like it is  
> today?
> That is a bit onerous, but maybe it's all userthreads deserve?
> ?
>
>
> Anyone who actually wanted to switch back and forth (Mika) would  
> just have two installs and two source trees?
>
>
> - Jay