-1

Assume this scenario :

class A{
public static B b=new B();
}

Class B{
}

Since the static variable is related to the type of that class, not to an instance of the class, so what points to the memory address of the heap? Seems that there should be something related to the type A that refers to the variable b stored in heap.

with special thanks to @user2864740, I got my answer and edited my question to clarify my meaning:

when the type A is loaded by the runtime, it's structure contains all sorts of information needed for the runtime to be able to allocate new instances and also the space for the static fields, in this case b.

The runtime has put the static field (b) at some offset from the start of the type A's data. This is different for each static type referenced.

Fahimeh Rahmatipoor
  • 93
  • 1
  • 10
  • 1
    According to your example, the static field `b` contains a reference to an instance of type `B`. What is not clear to you? – dymanoid Jul 20 '20 at 07:21
  • @dymanoid since b belongs to type A not any instance of A, is there any thing related to types (not objects) stored in stack memory? – Fahimeh Rahmatipoor Jul 20 '20 at 07:26
  • 2
    There is nothing related to types in .NET that can be placed on the stack - never. Please clarify your question. Why do you bother about the stack at all? – dymanoid Jul 20 '20 at 07:28
  • If the static filed b will always exist and it's existence has nothing to do with instantiation of A , but it it related to type A , so in an execution path how it can access to the instance of b, because maybe there are another static instances of B related to other classes like A. for static classes we have just one memory allocated for that static type, but in this case, b is just static for type A, and maybe there is another b1(for example) related to type C that has another static reference to B. – Fahimeh Rahmatipoor Jul 20 '20 at 07:42
  • 1
    I am sorry, but I still don't understand your question. What is your issue? There is no such thing as "static instance". Static is static, instance is instance - they don't mix. Could you please read our [ask] topics and then rewrite your question? You should provide a [mcve] and explain these things: what are you expecting, what is in fact happening, what does not work or what issues are you encountering (memory leaks, memory pressure, GC overload, etc) – dymanoid Jul 20 '20 at 08:54
  • Types, and instances of references types, are _not_ stored in the stack, so asking where in the stack they are stored **makes zero sense**. If you are willing to accept that the basic premise of your question is simply wrong, then we can move on to a discussion of where the static field _is_ stored. But that's been asked and answered many times already. See duplicates, which you might have found had you done some research before posting. – Peter Duniho Jul 20 '20 at 19:06

2 Answers2

0

Class A don't have to have an instance. It's static field b will always exist, also the instance assigned to it will also exist immediately - as it is static.

You can see this as a kind of how you want to have the instance be accessable.

The instanciation of A will have no influence on that. There will always be only one b.

Malior
  • 1,221
  • 8
  • 16
  • If the static filed b will always exist and it's existence has nothing to do with instantiation of A , but it it related to type A , so in an execution path how it can access to the instance of b, because maybe there are another static instances of B related to other classes like A. for static classes we have just one memory allocated for that static type, but in this case, b is just static for type A, and maybe there is another b1(for example) related to type C that has another static reference to B. – Fahimeh Rahmatipoor Jul 20 '20 at 07:42
  • You assigned the instance to the static field on startup. And then access it by "A.b". There could also be similar "C.b" - refering to an own instance. B is not a static class, you can have numberless instances. – Malior Jul 20 '20 at 08:02
  • I mean how memory manger in .net(gc) runtime can access it – Fahimeh Rahmatipoor Jul 20 '20 at 08:07
  • _"It's static field b will always exist, also the instance assigned to it will also exist immediately"_ -- not actually true. The class may not be initialized until it's actually accessed; the instanced assigned to the field `b` may not exist until the first time some code somewhere actually attempts to retrieve it. – Peter Duniho Jul 20 '20 at 21:46
0

Static variables “always” exist and represent strong roots (if they have no assigned value the point is moot).

As noted, static variables are stored independent of any instance. Consider that each loaded class type is also modeled as Type (ie. there is runtime metadata and designated internal implementation structures for each type). Conceptually, this is “how” such static variables can be associated and backed by specialized internal heaps.

However, the objects assigned to static variables follow normal “heap allocation” rules as the storage of a variable is different from the storage of objects it refers to. (So don’t worry about the implementation details of static variables.)

Relating to object lifetimes, value assignment to static members only occurs during and after static class initialization. That is, while static variables “always” exist, they are not always initialized.

In the above case, “new B()” is only invoked if something else causes A to go through static initialization. The ‘something else’ is an implementation detail, although it is guaranteed to occur before any static member is accessed or instance is created.

Thus the reachable lifetime of the object assigned to A::b is from the static initialization of A until the variable is re-assigned or the program ends. And in the shown code, there is no guarantee that A is ever initialized..

user2864740
  • 60,010
  • 15
  • 145
  • 220