On Thu, Nov 4, 2021 at 7:47 PM Andres Freund <and...@anarazel.de> wrote: > The immediate goal is to be able to generate JITed code/LLVM-IR that doesn't > contain any absolute pointer values. If the generated code doesn't change > regardless of any of the other contents of ExprEvalStep, we can still cache > the JIT optimization / code emission steps - which are the expensive bits.
I'm not sure why that requires all of this relative pointer stuff, honestly. Under that problem statement, we don't need everything to be one contiguous allocation. We just need it to have the same lifespan as the JITted code. If you introduced no relative pointers at all, you could still solve this problem: create a new memory context that contains all of the EvalExprSteps and all of the allocations upon which they depend, make sure everything you care about is allocated in that context, and don't destroy any of it until you destroy it all. Or another option would be: instead of having one giant allocation in which we have to place data of every different type, have one allocation per kind of thing. Figure out how many FunctionCallInfo objects we need and make an array of them. Figure out how many NullableDatum objects we need and make a separate array of those. And so on. Then just use pointers. I think that part of your motivation here is unrelated caching the JIT results: you also want to improve performance by increasing memory locality. That's a good goal as far as it goes, but maybe there's a way to be a little less ambitious and still get most of the benefit. -- Robert Haas EDB: http://www.enterprisedb.com
