How exactly do static fields work inside?

Question

Say you have a class,

class Foo { public static bar; } 

When you speak:

 new Foo(); 

I can imagine that space is reserved for this object in memory.

... and when you say again:

 new Foo(); 

... well, now you have another space for the object.

However, where exactly is the static field?

I'm really trying to learn:

How do object references refer to the same field of objects to which they refer?

Answer 1

Although the exact details of the type system are implementation dependent, let me delve deeper into more than just saying it depends, and you don't care. I will describe how it roughly works in a Microsoft (.NET) implementation according to the CLR book through C # by Jeffrey Richter , and the article See How CLR Creates Run-Time Objects by Hanu Kommalapati et al. ( Original MSDN May 2005 ).

---

Say you have a class:

 class Foo { // Instance fields string myBar = "Foobar"; int myNum; // Static fields static string bar = "Foobar"; static int num; } Foo myFoo = new Foo(); Type typeOfFoo = typeof(Foo); 

Where do the specimens live?

Whenever you say new Foo() , space is allocated and initialized for an instance of the object, and the constructor is called. This instance is shown as an instance of Foo in the image below. For example, an instance contains only the fields of the class instance (in this case myBar and myNum ), and for objects allocated on the heap, two additional fields used by the runtime ( Sync block index and Type handle ). A type pointer is a pointer to a Type object that describes the type of the instance, in this case the type is Foo.

When you say new Foo() again, a new space will be allocated that will again contain a space for the instance fields of this type. As you can see, instance fields are associated with object instances.

The runtime places each instance field with a fixed offset from the start of the object data. For example, myBar can live with an offset of +4. The instance field address is simply the address of the object plus the field offset.

Where do static fields live?

Static fields in C # and Java are not associated with any object instance, but with a type. Classes, structures, and enumerations are examples of types. Only once (for each type) is some space allocated for storing values ​​of static fields. It would be advisable to allocate space for static fields in the Type structure, which describes the type, since there is only one Type object for each type. This is the approach used by C # and Java.

A Type ¹ object is created when the type is loaded by the runtime. This structure contains all kinds of information necessary for the runtime to highlight new instances, call methods, and cast, among other things. It also contains space for static fields, in this case bar and num .

Runtime puts each static field at some offset from the start of the type data. This is different for each type. For example, bar can live with an offset of +64. The address of a static field is the address of the Type object plus the field offset. The type is statically known.

¹ ). In Microsoft.NET, several different structures describe a type, for example, the MethodTable method and EEClass structures.

Answer 2

It completely depends on the implementation in question. For C # and Java, the runtime allows you to determine where to store memory for a variable. For C and most compiled languages, the compiler makes this definition.

Saying this, in practice it does not matter. Its use is determined by the specification, so you can use the variable, knowing that the behavior will be guaranteed.

Answer 3

This varies greatly from language to language and can even vary greatly from platform to platform ...

For example, on the .NET side, static members are “associated” with the EEClass control definition, which can be allocated by a bunch of OR a “anywhere”, assigned by a member (C # spec does not indicate heap / stack behavior, this is part of the VM implementation)

Answer 4

There may be exceptions, but for reference types, new -keyword usually creates an object in an internal data structure called a heap. The heap is managed by the common language runtime (CLR). It doesn't matter if you have a static or instance element or a local variable.

The difference between static members and instance members (those that do not have the static ) is that static members exist only once for each type (class, structure), and instance members exist once for an instance (for each object )

This is just a link, static or not; this difference does not apply to a reference object (unless the object is a value type). A static member, an instance member, and a local variable can refer to the same object.

Answer 5

For Java, objects referenced by static fields will be on the heap , like other objects:

A heap is a run-time data area from which memory is allocated for all instances of classes and arrays.

The field will be initialized (if the declaration contains initialization) when the class is loaded , which happens immediately before the first occurrence of any one of the following:

• an instance of the class is created.
• The static method declared by the class is called.
• assigned a static field declared by the class.
• a static field declared by the class is used, and the field is not a constant variable (§4.12.4).

The static field is accessed using two special JVM instructions, getstatic and putstatic . But besides this difference, static fields are similar to non-static fields.

Answer 6

Im only familiar with C # and this is my understanding:

Then your program starts, it loads all the related assemblies into AppDomain. When assambly loads, all static constructors are called, including static fields. They will live there, and the only way to unload them is to unload AppDomain.

Answer 7

Static members and constants are stored on the heap. Unlike objects on the heap that can receive garbage collection, Static members and constants remain until the Appdomain is broken, so you need to be careful when working with static fields

Answer 8

Static variables belong to a class other than an object, so there is only one bar in memory, even if you initialize thousands of Foo moments.

Answer 9

It depends on language to language or language designer. If I'm talking about Java, static members are stored in the JVM Method area, and all objects are associated with them. It’s even more important to know that we can access a static data element without creating a class object. This means that allocating memory to static data members is independent of the creation of an object of this class.

Answer 10

By specification, static variables are stored in the Constant Pool . The JVM stores this information in the Permanent Generation.

Answer 11

Typically, static variables are stored in a data segment of program memory. therefore, for each class that is created / located in the current program, a static variable will be created in the data segment, and all other variables will be initialized in the code segment.

so basically it looks like

 +++++++++++++++++++++++++++++++++++++ + DATA Segment + -static vars + +---------------------------------- + instances | instances | instances| + | | | 

here a single area is shared between instances.

from wikipedia "The data area contains global and static variables used by the program that are explicitly initialized with a value."