Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Everyone knows that structs are value types and classes are reference types and that therefore structs are allocated on the stack and that objects are allocated on the heap.
What I'd like to know is what is the implication of something being allocated on the stack as opposed to something being allocated on the heap?
One general implication of allocating memory on the stack is that it is lost once it leaves scope (e.g., function/method returns). Heap memory can persist longer and need not worry about things like that.
Update:
Another important item that I didn't mention is that heap memory must be managed by someone. Depending on the language this can be the programmer (C, C++, etc.), a garbage collector (Java, C#, etc.). If heap memory isn't cleaned up when it's done being used you end up with memory leaks.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I read this article: https://medium.com/microsoft-open-source-stories/how-microsoft-rewrote-its-c-compiler-in-c-and-made-it-open-source-4ebed5646f98
Since C# has a built in garbage collector, is Roslyn slower than the previous compiler which was written in C++? Did they perform any benchmarks?
Let me address a question that you didn't explicitly ask but applies to your question.
Question: Is explicit garbage collection faster than implicit garbage collection?
Answer: As you may already know C++/C uses explicit garbage collection which means that free() must be called to deallocate memory allocated on the heap. On the other hand, C# uses implicit garbage collection which means the memory on the heap is deallocated in the background. The key here is implicit garbage collection will deallocate memory when needed at optimal times while explicit will always deallocate each object individually(if done correctly). Implicit garbage collection achieves this by communicating with the OS and by using some other algorithms. In all, in most situations, implicit garbage collection will perform better than explicit due to the above explanation. For more info check out this post.
Answer To Your Question: Because I have not seen any bench marks myself, it is almost impossible to say if one would be faster than the other for sure. There are many other features than garbage collection which would effect the speed of each langauge implementation. To clarify, C# is a bytecode based language that uses the JIT(Just-In-Time) compiler. If I had to choose, I would choose the C++ implementation to be faster due to the JIT optimizations lacking in some cases compared to the C++ compiler. Again, when it comes to how fast these two languages will perform it will depend on the situation. For example, there are some optimizations that JIT can preform that are impossible to do with the C++ compiler.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am curious about how clr knows particular object is not used by any other object and it is dead we know the basic of garbage collector but internally how clr find dead object.How clr knows the objects are in dead position.
https://msdn.microsoft.com/en-us/library/ee787088(v=vs.110).aspx#Anchor_4
A garbage collection has the following phases:
A marking phase that finds and creates a list of all live objects.
A relocating phase that updates the references to the objects that
will be compacted.
A compacting phase that reclaims the space occupied by the dead
objects and compacts the surviving objects. The compacting phase
moves objects that have survived a garbage collection toward the
older end of the segment.
The garbage collector uses the following information to determine whether objects are live:
Stack roots. Stack variables provided by the just-in-time (JIT)
compiler and stack walker.
Garbage collection handles. Handles that point to managed objects and
that can be allocated by user code or by the common language runtime.
Static data. Static objects in application domains that could be
referencing other objects. Each application domain keeps track of its
static objects.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to set automatically cleaning method for a desktop running application, because it throw an error "out of memory".
Is there any way to do this?
.
There is already an "automatic cleaning method"; the GC. You should virtually never need to tell it what to do - it understands memory more than most people do. If your code is throwing OOM, you need to investigate why; for example, are you leaking objects? (static event handlers are notorious for this); are you asking for huge slabs of contiguous memory (huge arrays, etc)? are you asking for an array that is more than 2 GiB (without large array support enabled)? are you running on 32-bit and just using lots of memory? is it actually not really an OOM condition, but really GDI+ handle exhaustion (which demonstrates in the same way)?
The first thing to check is how much memory your process is using - and how much free memory the OS has - when it throws OOM. If there is plenty of free memory, it isn't actually OOM (unless you're using over 1 GiB on a 32-bit system, in which case all bets are off).
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I want to know suppose I create an object and then use
(IDisposable(object)).Dispose() after using that object.
Will this help me to improve my performance?Or should I wait for GarbageCollector to collect that object?
The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.
Use the Dispose method of this interface to explicitly release unmanaged resources in conjunction with the garbage collector. The consumer of an object can call this method when the object is no longer needed
ref:
http://msdn.microsoft.com/en-us/library/system.idisposable(v=vs.110).aspx
A more detailed description
http://www.codeproject.com/Articles/413887/Understanding-and-Implementing-IDisposable-Interfa
Its purely depends on the context which we used, for example objects like DB connection objects usually needs to be disposed, any stream related operations needs to be disposed. It's not necessary to dispose every object which we create, most of them are handled by GC.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'd like to clarify an issue with CLR managed heaps. There are 2 object managed heaps - Large Object Heap and Small Object Heap. I know that objects which size is more than 85kbytes will be putted to the LOH. SOH has 3 Generations (0,1,2). The LOH is a part of SOH(2nd generation objects) or a separate heap with objects which always are 2nd gen? The LOH should be cleared along with 2nd gen object of the SOH?
Small Object Heap has generations that are checked from time to time. At the end of collection this heap is fragmented so it need to be compacte. If Large Objects were in this heep it would take long time for defragmentation. So they decided to have another heap Large Object Heap that will be exempt from this expensive operation of defragmenting.
There is really good book:
ftp://support.red-gate.com/ebooks/under-the-hood-of-net-memory-management-part1.pdf
page 55 LOH