Generate multiple functions with one instance of CodeGenerator about xbyak HOT 5 CLOSED

I'm sorry for slow response, I nothiced this issue today.

At first, assign large maxSize to the constructor of CodeGenerator.
I write the following code to avoid many instance of CodeGenerator.
Does this way solve your problem?

void *func1;
void *func2;
void *func3;
...

CodeGenerator()
{
#if 1
    func1 = getCurr();
    genFunc1();

    align(16);
    func2 = getCurr();
    genFunc2();

    align(16);
    func3 = getCurr();
    genFunc3();
#else
    // when using AutoGrow
    const size_t func1Offset = getSize(); // always 0
    genFunc1();

    align(16);
    genFunc2();
    const size_t func2Offset = getSize();

    align(16);
    genFunc3();
    const size_t func3Offset = getSize();
    ...
    func1 = getCode() + func1Offset;
    func2 = getCode() + func2Offset;
    func3 = getCode() + func3Offset;
#endif
}

from xbyak.

I avoided creating instances of CodeGenerator on the fly, just create some during program initialization, long initialization time isn't a problem in my case. The solution above might help, but not exactly what I want. Here is my problem:
I'm implementing something like a mini-SQL interpreter. Instead of interpreting everything, I want to use a JIT compiler/assembler to compile some SQL queries into machine code. So I need to generate and destroy unlimited number of functions. A light-weight JIT compiler/assembler is very important to my program.
If the solution above is used, I probably would generate and destroy functions in batches, for example, after generating 1k functions, destroy them all, then create another CodeGenerator instance. But cache problems might come into my way (just my guess, not sure): data cache miss, stale instruction cache etc.
Currently most queries are interpreted by my program, only very little functionality is implemented in JIT.

from xbyak.

Though I can't guess the cost of penalty of instruction cache miss, I try to add reset() method to CodeGenerator to reuse the instance at develop branch.
458a6e0
If this runs well, then I'll merge it into master branch.

from xbyak.

It's not just about performance.

On ARM CPUs, self-modifying applications have to invalidate instruction cache deliberately. I'm not sure about Intel/AMD CPUs. When multi-core systems, multi-threaded applications, old CPU architectures and all other things come together, things may get nasty.

from xbyak.

Of couse, it is bad to modify the region of code where CPU is running.
But Intel Processor supports Self-modifying code, so I think the problem is only about performance. I think we can get benefit if the generated functions are called many many times.

Intel optimization manual 3.6.9.1 Self-modifying code.

Self-modifying code (SMC) that ran correctly on Pentium III processors and prior
implementations will run correctly on subsequent implementations.

from xbyak.