Smaller HPyContext to prepare it for stack-allocation.

[fangerer]

We discussed having a stack-allocated context some time ago but never really made a decision nor summarized everything.
I wrote a document about that. Since that seemed to be a too long for an issue description, the document can be found in the Wiki:
https://github.com/hpyproject/hpy/wiki/Stack-allocated-HPyContext

[antocuni]

I read the wiki but I'm a bit confused about the terminology. If I understand it correctly, we are talking about two different things:

1. the layout of HPyContext: here the question is basically whether we want a single or double indirection is this correct?
2. how to allocate HPyContext: this is the stack vs heap allocation discussion, but again if I understand correctly it's a graalpython specific discussion, isn't it? E.g., for CPython and PyPy the HPyContext will likely continue to be a singleton.

And the link between (1) and (2) is that stack allocation is possible only if sizeof(HPyContext) is small, i.e. only if we use double indirection.

Is my summary correct, or I am missing anything?

[fangerer]

Concerning the link: yes.

You are right. If we change the context layout to what I've suggested, then other runtimes are still free to allocate the context on the heap. I'll try to make that clear in the document ASAP.

[antocuni]

I am not opposed to change the layout of HPyContext, but the first thing to do is to measure the performance penalty and then decide based on that (especially on CPython)

[fangerer]

I absolutely agree. I will design various benchmarks.

[hodgestar]

One way to make the context slightly smaller would be to replace the ctx->h_None and similar handles with a fixed list of constant handles. This would be most awkward on CPython where the handles currently really are pointers.