-
Notifications
You must be signed in to change notification settings - Fork 4.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[API Proposal]: Get the managed size of a System.Type instance #97344
Comments
Tagging subscribers to this area: @dotnet/area-system-runtime Issue DetailsBackground and motivationAs part of the same problem as #97341, we have a scenario where we have a This issue proposes a new method to get the size of the instance of a managed type from its API Proposalnamespace System.Runtime.CompilerServices;
public class RuntimeHelpers
{
+ public static int SizeOf(RuntimeTypeHandle type);
} API Usagevar abi_element_size = RuntimeHelpers.SizeOf(AbiType.TypeHandle);
var byte_length = length * abi_element_size;
m._array = Marshal.AllocCoTaskMem(byte_length);
m._marshalers = new object[length];
var element = (byte*)m._array.ToPointer();
for (int i = 0; i < length; i++)
{
m._marshalers[i] = Marshaler<T>.CreateMarshaler(array[i]);
Marshaler<T>.CopyAbi(m._marshalers[i], (IntPtr)element);
element += abi_element_size;
} Alternative DesignsWe could place the API on RisksNo response
|
Related #24200 |
Would this work for both reference types and value types? My proposal would be to either make this throw for non-valuetypes, or have it return Size of classes is tricky (do we want the aligned or unaligned size?) and unless we have a use case to decide what size this is, it's better to just proactively block it. Nothing good would probably come out of it. |
I honestly don't care about the experience for reference types. I only need this for value types. I think either having it throw or return Since this is proposed as "sizeof(T) but with a dynamic T", I'd be inclined to return |
Should it be namespace System.Runtime.CompilerServices
{
public static class Unsafe
{
public static int SizeOf<T>();
+ public static int SizeOf(Type type);
... instead? To improve API discoverability and I think we use this pattern for some other APIs, e.g. |
👍 to Egor's suggestion, having it as a neighboring overload is definitely more consistent with how we do it for other overloads. Is there any particular reason why it needs to be |
I'm like using RuntimeTypeHandle when it needs to be a runtime-loaded type as opposed to a user-provided derived type. I'm okay changing it if that's desirable. |
Are there any benefits or drawbacks to using one over the other here? AFAIR, |
If the API takes Type, it needs to validate whether the Type is RuntimeType first. This validation takes a few extra instructions. Type is more usable. RuntimeTypeHandle is more oriented towards low-level perf oriented.
If you know the concrete type, it is better to use the existing generic SizeOf method. It is going to faster (or at least as fast) than this method. |
Sounds like |
namespace System.Runtime.CompilerServices;
public partial class RuntimeHelpers
{
public static int SizeOf(RuntimeTypeHandle type);
} |
Background and motivation
As part of the same problem as #97341, we have a scenario where we have a
System.Type
, we cannot rewrite the code in an AOT-safe manner to represent the type as a generic argument, and we want to be able to callUnsafe.SizeOf<T>
for ourSystem.Type
instance.This issue proposes a new method to get the size of the instance of a managed type from its
RuntimeTypeHandle
.API Proposal
namespace System.Runtime.CompilerServices; public class RuntimeHelpers { + public static int SizeOf(RuntimeTypeHandle type); }
API Usage
Alternative Designs
We could place the API on
System.Runtime.CompilerServices.Unsafe
next toSizeOf<T>()
.Risks
No response
The text was updated successfully, but these errors were encountered: