Ok, thanks for making it clear.

You are indeed right: it's very smooth and easy to use like this. It's just that it's hard to rely on it as a separate project: who knows if it will be updated in the future if something breaks with new versions of angelscript.

Anyway, it's working very well right now, so no worries!

I am not sure what the right place is to post this, but since we have been talking about the JIT in this thread, I thought it might be useful for others...

I have found a memory leak in the JIT, and it seems that the fix is pretty simple. Just removing the "else" branch in the following code (as_jit.cpp) seems to do the trick (It looks like a typo or a merge issue btw)

//Get the active page, or create a new one if the current one is missing or too small (256 bytes for the entry and a few ops)
if(activePage == 0 || activePage->final || activePage->getFreeSize() < 256)
  activePage = new CodePage(codePageSize, reinterpret_cast<void*>(&toSize));
else
  activePage->grab();
activePage->grab();

When changed into the following code, the leak disappears, and the JIT seems to be still working well. It simply removes the duplicate call to "grab" when the page already exists.

//Get the active page, or create a new one if the current one is missing or too small (256 bytes for the entry and a few ops)
if(activePage == 0 || activePage->final || activePage->getFreeSize() < 256)
  activePage = new CodePage(codePageSize, reinterpret_cast<void*>(&toSize));

activePage->grab();

Oh, thanks for that report, I'll fix it in the repo. If you discover more issues, please report them to the github and I'll fix them as I get time.

Ok, thanks! I did not know which place was appropriate. BTW, it's working VERY well so far. And performance is really impressive!

Any chance you can come up with an ARM implementation in the future? :-)

Hi,

just a quick heads up to warn you that the leak fix above works fine on windows but seems to be causing random crashes on Mac (the memory debugger sees double freed memory here and there). I must say that I have no clue about why the behavior is different. I guess there is something I have misunderstood in the code of the JIT.

(Note: the leak is however found on Mac too).

We discovered a bug while applying your fix where CodePages allocated in the GCC version had uninitialized reference counts. You just need to default-initialize references to 1 in CodePage's constructor and it should be fixed.

Thanks! This fix+mine remove the leaks and now work fine on both Mac and Windows, that's great!

I had not noticed that it was indeed implemented differently on Window and Mac. I only debugged the Windows version to check reference counts, so I did not see this problem in the first place.

This could be done without any new bytecode instructions in the vm.

What you need is some way to tell the compiler to produce the bytecode for acessing the buffer memory directly like a class property, instead of calling the opIndex method.

How would you approach this? Create a new behavior (along the lines of asBEHAVE_TEMPLATE_CALLBACK) that, if present, the compiler will call that function to get the offset of the buffer within the object as well as the size of each element? With these two things, plus the address of the object and the index to be accessed.. should possibly be enough to generate byte code in CompileExpressionPostOp() that's similar to the '.' case?

That way the array add_on (or whatever C++ class) would have to define that behavior in the first place, making it an opt-in thing (shouldn't affect any existing scripts), plus it would get the callback for each new template subtype to tell the compiler whether 'direct access' should be used for that kind of array?

Yes, that sounds like a workable solution.

I got to the point where in the compiler code that would typically output the opindex call, I can check whether the type has registered a 'direct array access' behavior, similar to the template callback one.. however, I need know the size of each array element. I can probably get that off the subtype (?).

Also, CScriptArray news up a SArrayBuffer struct for some reason instead of having the two DWORDS and a pointer as member variables. I'd probably need to make them member variables in order to be able to do a C++-compile-time offsetof() from the CScriptArray instance to the data pointer, so that I can get at the beginning address of the data.