7
What is the behavior of static variables in . NET? These are stored in heap or in the stack?
2 answers
9
Static data, not only variables, constants and codes as well, are stored in a heap special, called High Frequency Heap. It is an area managed by . NET, but its content is not collected. There is stored what the application needs for its entire life. Static data is stored there from its first use until the application is finished, unlike heap normal where data is collected when there are no more references to them at the time one of the generations triggers a collection.
In fact there is a collection from this area when a AppDomain is discharged. What is nevertheless the end of the application in a certain sense. Certainly at the end of the AppDomain you will no longer be able to access this data. The general allocation of this memory area occurs on the AppDomain. Mo . NET Core no more AppDoamin. But this mechanism was abandoned in recent versions of . NET.
Static data is never on stack or heap normal. It would not make sense since these data are not transitory (to better understand these areas read What they are and where the stack and heap are). The special HFH area is within the heap but it has a special treatment. Of course static data (variables, codes, etc.) can refer to the stack or heap.
It is important to note that even data by value who would normally be in stack or in the heap (see more in Memory allocation in C# - Value types and reference types) are stored in this area when they are static.
Note that if a static variable is a type by reference only the reference will be in this area, the object itself will be in the heap normal. There are exceptions, such as striung which was defined by a literal.
A literal of the kind string is a static data and it is stored only once even if it appears several times in the code through a technique called interning.
Remember that a static object is allocated only once and is not reallocated by definition.
The Jitter uses this same area to allocate the generated codes.
Of course all this is implementation detail. Nothing prevents that in future versions will be changed, although unlikely to happen. In fact the importance of this information for the programmer is small. The most important thing is to know that they are stored very quickly (generally comparable to the time spent on stack or a little better) and how not soulless nor liberates, there is no other cost.
-
You refer to the term static as being a value that doesn’t change, but I don’t think it’s quite right to say that when it comes to C#, static variables created with keyword Static can have their value modified, and to say that a string is a static data is not the best way to define this, the term most used for this is the immutable, since any modification in the string generates a new object, while the string object itself will not be modified its variable can now reference another object
-
@Leandrogodoyrosa no, variables have values that change and they can be static. Reli and I did not find in the text what you are saying. Can you quote where I seem to say this? You know what a literal is string? They cannot be modified. Variables string can. If you do not understand the subject, you can ask a question and I will be happy to answer.
1
The parts of a Java program (variables, methods and objects) live in one of the two places in memory: Stack and Heap.
Instance variables and objects are stored in Heap (or static), and local variables are stored in the Stack (battery, automatic).
Stack is the execution stack. Each executed method is placed on the stack. Thus, the code of methods and local variables (including parameters) are placed in the Stack. If a method fills the Stack, the exception StackOverflowException will be launched; this means that the Stack has grown so much that it has invaded an area that does not belong to it.
Heap is the place where instantiated objects are located, that is, where instance variables and references (objects) are placed. When a method creates many instance variables to the point of filling the Heap, the exception OutOfMemoryError is launched.
import java.util.Date;
public class Agenda {
//variável de instância - heap
Date data;
//método - stack
public static void main(String[] args) {
//variável local - stack
Date dt = new Date();
Agenda agenda = new Agenda();
agenda.setData(dt);
}
//parâmetro - stack
public void setData(Date d) {
data = d;
}
}
Source: http://kamilladoria.blogspot.com.br/2010/05/stack-e-heap.html
-
Good answer. However, this is not restricted only to Java. It is a feature of the current processor architecture. This concerns running-time memory management of a program. But in a very brief way it follows as you said: stack is where the local variables of a method are instantiated, including parameters; and heap is where the global variables are instantiated; all at runtime.
-
1
In the past, the most common memory corruption errors were Stack Overflow and Heap Overflow. Such errors generate security holes, which allow code injection and program execution flow redirection, enabling remote shell opening or privilege escalation. And to this day, such failures are exploited.
-
Just a semantic correction: I don’t remember my Compiler lessons anymore, but I think heap and stack are features of the memory management of operating systems and not the architecture of processors. At least I didn’t find any Assembly x86 instruction regarding heap, and do not know if the part of manipulation of stack is the same thing in both.
Browser other questions tagged c# memory-management stack clr heap
You are not signed in. Login or sign up in order to post.
Related: what they are and where the stack and heap are
– rray
I edited to remove the part that was duplicated. The part that remains has no answer on the site and I will respond. The edit did not invalidate the existing answer because it was already invalid. An answer about Java in a C# question does nothing to help. Even if the question was about Java, the answer has errors, which is worrying since the indirect source is a Sun study guide for Java certification. Maybe this will help explain a little why there are so many bad Java programmers.
– Maniero