XArch: Trim the code block to match the actual code length

[kunalspathak]

RyuJIT sometimes over-estimate the instruction sizes leading to allocating more code memory than actually utilized. This PR reads the actual code size value and trims the code block array so that the real code size bytes are embedded in the R2RImage.

Related: #57368

[kunalspathak]

@jkotas @davidwrighton @dotnet/jit-contrib

[kunalspathak]

@mangod9

[jkotas]

Thanks

[kunalspathak]

Also realized that this is only applicable for xarch. For arm64, we also include the size of ro data and hence checking the unused memory is not even possible.

[jkotas]

Also realized that this is only applicable for xarch. For arm64, we also include the size of ro data and hence checking the unused memory is not even possible.

Mention this in the comment?

[kunalspathak]

Mention this in the comment?

Sure, I have included some more explanation about armarch.

[BruceForstall]

The comment at

runtime/src/coreclr/inc/corjit.h

Lines 184 to 187 in 16b970a

	// JIT to resolve tokens, and make any other callbacks needed to create the code. nativeEntry, and
	// nativeSizeOfCode are just for convenience because the JIT asks the EE for the memory to emit code into
	// (see code:ICorJitInfo.allocMem), so really the EE already knows where the method starts and how big
	// it is (in fact, it could be in more than one chunk).

for compileMethod is no longer quite true, as now the returned nativeEntry has specific semantics... for some platforms.

That's somewhat unsatisfying.

[kunalspathak]

Failure related to #61548

@BruceForstall - Do you mind taking another look?

[BruceForstall]

I'm still not fond of the fact this creates an implicit contract that isn't documented (in corjit.h), and not for all platforms. But ok...

[kunalspathak]

@BruceForstall and me discussed a possible follow-up work of implementing a new JITEE interface for reportMem() that will be useful for crossgen and JIT scenarios.