asBC_Thiscall1, the new opcode for fast array access, is implemented using the same function call compilation path that asBC_CALLSYS was already using.

It's faster in the VM because it avoids code that isn't needed for simple function signatures, but since the JIT was never emitting that code during function call compilation when not needed anyway, it's not going to make a difference in JITed code.

We started using JIT but found that script expressions of form

string s = b ? "A" : "B";

cause access violation errors. This issue appears to be exclusive to strings and only happens with string literals. In particular, the expression

string s = b ? string("A") : string("B"); 

will not cause a crash. Judging by another report, there may also be an error when passing a string literal to a function that takes a string argument by value, but I didn't have time to investigate that case yet.

Thanks, I'll check it out. What platform are you running on?

I vaguely remember something being weird about ternary expressions myself somewhere, so I'll have to take a look soon and see what's up.

The code is compiled for 32-bit Windows and tested on 64-bit Windows.

I found a bug in the JIT that could cause ternary operators to behave unpredictably in certain situations. I've pushed a fix for it to the github repository.

I don't know if this was the cause of the problem you were experiencing. I could certainly see it cause segfaults in certain situations, although it didn't for me (it just made the ternary pick the wrong case sometimes).

I can't reproduce any problem with string literals in ternaries at the moment, if you're still having trouble with them in the latest commit something else might be wrong.

I tested the latest revision but unfortunately it didn't solve the issue. However, I noticed that the error doesn't occur for global string instances, so this may be what's preventing you from reproducing it. The smallest piece of code that I can use to reproduce the error is

void main() {
	string a = true ? "a" : "b";
}

However, if at least one of "a" and "b" is wrapped in an explicit string constructor, the code seems to work correctly. The access violation reliably occurs while executing (rather than compiling) the code. It comes from CopyConstructString in scriptstdstring.cpp, which is called with an invalid reference as the other argument. The reference appears to reliably be to address 0x00000001.

I also investigated the other report I got and determined that it's an unrelated access violation caused by line 3003 of as_jit.cpp, when the code is trying to dereference it->second.jitFunction. The error occurs relatively rarely, after the program runs several scripts. It would appear to me that entries are never removed from the deferredPointers multimap, and thus as the engine releases old functions and allocates new ones, it has an ever increasing chance of allocating one at an address already present among deferredPointers keys, with unexpected consequences.