[clr-interp] Implement CEE_LOCALLOC and frame data allocator for dynamic stack allocations

[kotlarmilos]

Description

This PR adds support for the CEE_LOCALLOC and frame data allocator to the interpreter for handling dynamic stack allocations.

Changes

• Implemented CEE_LOCALLOC with a frame data allocator for dynamic stack memory
• Implemented overflow-check multiplication operations used in the interpreter to evaluate stackalloc arguments
• Implemented FrameDataAllocator based on the existing allocator

  runtime/src/mono/mono/mini/interp/interp-internals.h

  Lines 219 to 225 in d9c4c3e

  	typedef struct {
  	FrameDataFragment *first, *current;
  	FrameDataInfo *infos;
  	int infos_len, infos_capacity;
  	/* For GC sync */
  	int inited;
  	} FrameDataAllocator;

Validation

Tests in Interpreter.cs covering frame data allocator scenarios.

[Copilot]

Pull Request Overview

This PR implements dynamic stack allocation capabilities in the interpreter by introducing a frame data allocator and adding support for the CEE_LOCALLOC opcode.

• Added comprehensive tests for localloc operations in Interpreter.cs
• Implemented frame data allocator infrastructure and dynamic memory allocation functions in interpexec.{h,cpp}
• Updated the interpreter compiler to generate code for CEE_LOCALLOC and overflow-check multiplication opcodes

Reviewed Changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 1 comment.

File	Description
src/tests/JIT/interpreter/Interpreter.cs	Added tests for dynamic stack allocation via TestLocalloc()
src/coreclr/vm/interpexec.h	Added definitions for FrameDataFragment, FrameDataInfo, and FrameDataAllocator structures
src/coreclr/vm/interpexec.cpp	Implemented functions for managing dynamic stack memory and added INTOP_LOCALLOC opcode handling
src/coreclr/interpreter/compiler.cpp	Updated code generation to support CEE_LOCALLOC and checked overflow multiplication opcodes

Files not reviewed (1)

• src/coreclr/interpreter/intops.def: Language not supported

Comments suppressed due to low confidence (2)

src/coreclr/vm/interpexec.cpp:1266

• Ensure that the ALIGN_UP macro and related allocation logic correctly enforce the required alignment for dynamic stack allocations to avoid subtle memory issues.

mem = frame_data_alloc(&pThreadContext->frameDataAllocator, (InterpreterFrame*)pFrame, ALIGN_UP(len, INTERP_STACK_ALIGNMENT));

src/coreclr/interpreter/compiler.cpp:3145

• The handling of the CEE_LOCALLOC opcode involves pointer arithmetic and stack pointer adjustments; please verify that these operations maintain the stack invariants under all conditions to prevent runtime errors.

case CEE_LOCALLOC:

[dotnet-policy-service]

Tagging subscribers to this area: @BrzVlad, @janvorli, @kg
See info in area-owners.md if you want to be subscribed.

[janvorli]

I am not sure how can we delete the allocator here. If I understand it correctly, we allocate it in the InterpGetThreadContext, but only if the t_pThreadContext was not set yet. And we delete it here when we exit from a block of interpreted frames that can happen many times. E.g. with the EH, a catch funclet exits here and then we resume in the parent function after the catch. That means that after resuming from catch, the pFrameDataAllocator would be invalid.

[kotlarmilos]

That workaround was only temporary, but you are right. I’ve now implemented a destructor for InterpThreadContext. Please let me know if there is a deterministic place to destroy the thread context.

If this approach is reasonable, I would move the initialization into the constructor instead.

[janvorli]

I would prefer moving the InterpThreadContext instance to the coreclr Thread class instead and performing the cleanup in the Thread::~Thread or Thread::OnThreadTerminate. Having a thread local object with a destructor is a recipe for possible problems due to the fact that the order of their destruction is arbitrary.

[kotlarmilos]

Implemented the InterpThreadContext constructor and destructor, and moved its instance into the CoreCLR Thread class. It is now created lazily on first pThread->GetInterpThreadContext() in prestub.cpp. This ensures that all allocated memory is properly released when the Thread destructor runs.

[jkotas]

Suggested change

	pMemory = pThreadContext->frameDataAllocator.Alloc(pFrame, &len);
	pMemory = pThreadContext->frameDataAllocator.Alloc(pFrame, len);

It is not necessary to use the aligned length for memset. We just need to clear the memory that the user code asked for. We do not need to clear the extra padding.

[janvorli]

LGTM, thank you!