Why box field is required in integer in ILDASM

Hemalatha Sunnapu

8y1.1k.NET

.method public hidebysig instance void fun(string h) cil managed

{

// Code size 133 (0x85)

.maxstack 2

.locals init (int32 V_0)

IL_0000: nop

IL_0001: ldstr "base called from "

IL_0006: ldarg.0

IL_0007: ldfld int64 ConsoleApp6.Base::x

IL_000c: box [System.Runtime]System.Int64

IL_0011: call string [System.Runtime]System.String::Concat(object,

object)

IL_0016: call void [System.Console]System.Console::Write(string)

IL_001b: nop

IL_001c: nop

IL_001d: ldstr "x value next after declartion is"

IL_0022: ldarg.0

IL_0023: ldfld int64 ConsoleApp6.Base::x

IL_0028: box [System.Runtime]System.Int64

IL_002d: call string [System.Runtime]System.String::Concat(object,

object)

7 Replies

Know the answer? Post it — somebody with the same question will find it here.

Karthik Chintala8y ago
Accepted answer
A good question by the way.

What I understand from the IL is that you are trying to print the value of x using Console.Write() method.

Why box is performed?

Console.Write() method accepts any type of object. In your code, you are using with the string overload version.

Console.Write("base called from " + x);

The above code just looks ok for us and we'll say yeah this will print "base called from x". But, from IL point of view, it has to do the following
Load the instruction x on to the stack
A box instruction is issued on x to convert it into an object (Why? because you are utilizing the x in concat; the value type x should be popped from the stack. So, a box operation is performed).
Now, the value to be concatenated is "base called from " and object x (the boxed form)
A string.Concat is issued on both the objects
It's the basics of the stack why to perform a box instruction.

The stack transitional behavior, in sequential order, is:

A value type is pushed onto the stack.

The value type is popped from the stack; the box operation is performed.
An object reference to the resulting "boxed" value type is pushed onto the stack.
The above lines are from MSDN (https://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.box(v=vs.110).aspx)

So, Why box?

When a field has to be utilized and it is popped from the stack an automatic box operation is performed.

To test this just print out a string without any concatenations to your long variable. There will not be any box operation anymore.

Hope you understand what's happening in the I
Hemalatha Sunnapu8y ago
A small doubt , as we know that
objects gets stored on heap because the size of the object is unknown and
value types gets stored on stack because, CLR knows the size of them .
Here comes my question.
Object has got converted from value type integer whose size well known , then why it would get stored on heap rather than stack?
Hemalatha Sunnapu8y ago
Ok , not only value types even headers gets stored on stack memory.
Karthik Chintala8y ago
Yes, the object header is stored on stack only.
Hemalatha Sunnapu8y ago
Hello Karthik,

That was very nice.

And i got clear my doubt, As they have mentioned ....

When a value is boxed it gets an object header. The kind that any type that derives from System.Object has. The value follows that header. The header contains two fields, one is the "syncblk".

I think object header is stored on Stack memory. Is it so?
Karthik Chintala8y ago
You can check @Hans Passant answer for more detailed information on it.

https://stackoverflow.com/questions/25035332/how-runtime-knows-the-exact-type-of-a-boxed-value-type

If you don't understand, check @Ritesh answer in above thread.
Hemalatha Sunnapu8y ago
Hello Karthik,

Thank you for your answer.

Coming to the answer , you said

3.An object reference to the resulting "boxed" value type is pushed onto the stack.

Is that object X will be stored on heap memory?