`UnsupportedSpecializationException`: Unexpected values provided for `ContextObjectWriteNodeGen` when creating `Context` instances manually

[LinqLover]

Practical example to reproduce:

• Install/get an image with SimulationStudio (for instance, the image from this bundle should do it)
• Do it:

  Simulator evaluate: [1 + 2]

• Expected behavior: Answers 3
• Actual behavior: crash (UnsupportedSpecializationException: Unexpected values provided for ContextObjectWriteNodeGen)

Minimal example to debug:

• Do it:

  thisContext privSender: Object new.

• Expected behavior: A cannotReturn: is put on the stack (and subsequently, the current project is emergency-exited because the debugger cannot display the stack, but the VM keeps alive - see OSVM for reference)
• Actual behavior: VM crashes, same error as above

---

It would be nice if TruffleSqueak could be more robust with regard to unusual contexts - just like the OpenSmalltalk VM, which does not raise an error unless the interpreter actually attempts to return to an invalid sender on the context.

For some background: SimulationStudio is relying on the possibility to put arbitrary objects (subinstances of Context) on the stack to modify the behavior of the image-side simulator while reusing the Context interface. These objects are never actually interpreted by the VM, but the simulation protocol on Context can handle them like regular contexts.

[fniephaus]

Thanks for raising the issue! So far, TruffleSqueak is quite constrained as to what you can do with Contexts because they are very performance-critical. Historically, we only added support for the things usually used by Squeak/Smalltalk and its tests and intentionally sprinkled bits and pieces that help us find new cases that need to be supported: e.g., there are lots of assertions and, as you found out, tight specializations that trigger UnsupportedSpecializationExceptions.

In this particular case, TruffleSqueak only allows setting the sender to another Context object or nil:

trufflesqueak/src/de.hpi.swa.trufflesqueak/src/de/hpi/swa/trufflesqueak/nodes/accessing/ContextObjectNodes.java

Lines 79 to 88 in a068eca

	@Specialization(guards = "index == SENDER_OR_NIL")
	protected static final void doSender(final ContextObject context, @SuppressWarnings("unused") final long index, final ContextObject value) {
	context.setSender(value);
	}
	@SuppressWarnings("unused")
	@Specialization(guards = "index == SENDER_OR_NIL")
	protected static final void doSender(final ContextObject context, final long index, final NilObject value) {
	context.removeSender();
	}

We should be able to allow arbitrary objects because the sender is maintained in the Truffle frame arguments:

trufflesqueak/src/de.hpi.swa.trufflesqueak/src/de/hpi/swa/trufflesqueak/util/FrameAccess.java

Lines 45 to 47 in a068eca

	* SENDER_OR_SENDER_MARKER -> | FrameMarker: virtual sender |
	* | ContextObject: materialized |
	* | nil: terminated / top-level |

However, it makes me quite nervous that someone does this because you'll definitely run into very weird problems (or more likely a simple crash) when that sender is suddenly accessed for execution.
Nonetheless, TruffleSqueak should allow this at some point and use cannotReturn: correctly.

[LinqLover]

Thank you for the feedback!

However, it makes me quite nervous that someone does this because you'll definitely run into very weird problems (or more likely a simple crash) when that sender is suddenly accessed for execution.

Couldn't this check be moved into the interpretation of the return instructions? E.g., the VM-side equivalent of blockReturnTop/methodReturnTop. Or would this limit the performance as you mentioned?

I can only tell that the OSVM has survived all my attempts so far to install any invalid senders on the stack :D

[fniephaus]

Couldn't this check be moved into the interpretation of the return instructions? E.g., the VM-side equivalent of blockReturnTop/methodReturnTop. Or would this limit the performance as you mentioned?

Yes, that should be possible. The reason things are as they are is because we tried to avoid/catch propagation of "invalid" state as early as possible. Of course, "invalid" stands for "unusual" here. ;)

I can only tell that the OSVM has survived all my attempts so far to install any invalid senders on the stack :D

Good! I wish we could say the same about TruffleSqueak...maybe some day! :)