[M3devel] frame per procedure instead of frame per TRY?

[Elmar Stellnberger]

Am 2015-07-19 um 11:10 schrieb Jay K:
> I'm pretty sure it can work, but you need also a local "dense" 
> volatile integer that describes where in the function you are.  That 
> isn't free, but it is much cheaper than calling setjmp/PushFrame for 
> each try.
>
Is it really that much faster? I can remember having implemented my own 
setjump/longjump in assembly some time ago and it should only save you 
one procedure call but generate some additional jumps. However I do not 
know how time costly the new-fashioned register value obfuscation is 
(registers are no more stored as they are but obfuscated for security 
reasons by glibc). Xor-ing by a simple value; does it really cost the 
world? I am not the one who can tell you whether such a venture like 
this would pay off ...


>
> Try writing similar C++ for NT/x86 and look at what you get.
> "PushFrame" is highly optimized to build a linked list through fs:0.
> And even that is only done at most once per function.

Through fs:0 ? It used to be on the ss:[e/r]b in former times.
Since pthreading it may also be fs:0 under Linux because of get/setspecific.
I am not sure what these functions do in detail (something with fs at last).

Nonetheless I would believe that avoiding to call get/setspecific could 
speed
things up noticeably. First there is the function overhead, second we 
need to
touch an independent memory area and last but not least the stack is
always thread local. However I am not sure on how we could place the top
anchor for the linked list of exception frames otherwise. Push an exception
  frame pointer into every local variable area?

>
>
> Java VM also specifies scope tables with a similar intent.

However Java is not known for speed wonders ...


>
>
> The key is figuring out the algorithm to assign the scope ids, and 
> computing and interpreting the resulting tables. It is a little tricky.
>


Am 2015-07-19 um 11:18 schrieb Jay K:
> The stack pages must be touched in order...

Thanks a lot for an elaborate discussion of this!



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20150719/bc13a4ff/attachment-0002.html>