I've lamented here and elsewhere some unfortunate inconveniences and asymmetries in the CLR -- for example, we have nullable structs but lack non-nullable reference types, an issue I address in my Sasa class library.
I've recently completed some Sasa abstractions for safe reflection, and an IL rewriter based on Mono.Cecil which allows C# source code to specify type constraints that are supported by the CLR but unnecessarily restricted in C#. In the process, I came across another unjustified decision regarding verification: the jmp instruction.
The jmp instruction strikes me as potentially incredibly useful for alternative dispatch techniques, and yet I recently discovered that it's classified as unverifiable. This seems very odd, since the instruction is fully statically typed, and I can't think of a way its use could corrupt the VM.
In short, the instruction performs a control transfer to a named method with a signature matching exactly the current method's signature, as long as the evaluation stack is empty and you are not currently in a try-catch block (see section 3.37 of the ECMA specification).
This seems eminently verifiable given a simple control-flow analysis, an analysis which the verifier already performs to verify control-flow safety of some other verifiable instructions. If anyone can shed some light on this I would appreciate it.
I've recently completed some Sasa abstractions for safe reflection, and an IL rewriter based on Mono.Cecil which allows C# source code to specify type constraints that are supported by the CLR but unnecessarily restricted in C#. In the process, I came across another unjustified decision regarding verification: the jmp instruction.
The jmp instruction strikes me as potentially incredibly useful for alternative dispatch techniques, and yet I recently discovered that it's classified as unverifiable. This seems very odd, since the instruction is fully statically typed, and I can't think of a way its use could corrupt the VM.
In short, the instruction performs a control transfer to a named method with a signature matching exactly the current method's signature, as long as the evaluation stack is empty and you are not currently in a try-catch block (see section 3.37 of the ECMA specification).
This seems eminently verifiable given a simple control-flow analysis, an analysis which the verifier already performs to verify control-flow safety of some other verifiable instructions. If anyone can shed some light on this I would appreciate it.
Comments
It would otherwise require much more sophisticated verification rules.
Besides possible historical artifacts and mistakes, one issue is that some implementation specific constraints could make it impossible to implement jmp. And unlike the tail prefix, it doesn't allow for conditional execution.
Honestly, I never got it, the need for jmp. A tail call can do the exect same thing and be JIT'd to the same code sequence.
If you just meant an ordinary reference, then I disagree that this is unsafe.
If you meant an actual unsafe pointer, well we're already handling unsafe types so verification isn't an issue.
I agree that general tail calls are better, but MS is kind of stubborn that tail calls remain inefficient. JMP just seemed like a sort of middle ground that might be useful in lieu of tail calls for some scenarios.
Finally, I disagree that it doesn't allow for conditional execution. All that's required is that the evaluation stack is empty and you're not in a protected block. This should be more or less valid:
IL_001: ldnull
IL_002: brtrue IL_004
IL_003: jmp void Target1(void)
IL_004: jmp void Target2(void)
Tail calls/jmp to methods with such kind of parameters are not verifiable without complex dataflow analysis or significant restrictions.
I did use a very bad wording for 'conditional execution' of tail calls. I meant that a CLI implementation is not required to obey a tail prefix, while it must for jmp.
A control-flow analysis to detect whether the starg and the jmp are ever on the same execution path is just a nice refinement.
void RemoveAt(int i)
{ /* verify the index and call RemoveAtCore */ }
void RemoveAtCore(int i)
This allows code inside the class to bypass the index check if the caller knows it's safe. A tail call helps, but a jmp might be more efficient since you know the JIT won't duplicate the argument(s).
It is irritating also that tail calls cannot be guaranteed to work, so self-recursive functions can cause stack overflow in cases where the equivalent code in Haskell couldn't.
Anyway, surely the verifier should at least allow jmp in cases where there are no "ref" args (given that it would be so little work to implement.)