[M3commit] how to switch userthreads on/off
Tony Hosking
hosking at cs.purdue.edu
Wed Apr 29 20:27:49 CEST 2009
I'd prefer user threads to be deprecated merely because multi-core is
prevalent now. If someone needs them let them recompile.
On 29 Apr 2009, at 10:06, Jay 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
More information about the M3commit
mailing list