6

When creating 2 objects of the same type, will the handle from the stack memory point to the same object in the heap or will it point to 2 separate objects. For clarity here is the specific question...

class Q2 {
   private static int num = 0;
   private String prefix;

   public Q2 (String p)
    { prefix = p; }

   public String Msg (String str) {
      String n;
      num++;   
      n = num.ToString();
     return n + " - " + prefix + str;
   }
}

Using an appropriate diagram, describe the state of memory after all of the following statements have been executed.

 Q2 var1, var2;
   var1 = new Q2("Question 2");
   var2 = new Q2 ("Another view");

Here are the answers I cannot decide between:

1 object:

enter image description here

2 objects:

enter image description here

trincot
  • 317,000
  • 35
  • 244
  • 286
aelsheikh
  • 2,268
  • 5
  • 26
  • 41

4 Answers4

4

To help clarify the discussion on the heaps here, there are about 8 different heaps that the CLR uses:

  1. Loader Heap: contains CLR structures and the type system
  2. High Frequency Heap: statics, MethodTables, FieldDescs, interface map
  3. Low Frequency Heap: EEClass, ClassLoader and lookup tables
  4. Stub Heap: stubs for CAS, COM wrappers, P/Invoke
  5. Large Object Heap: memory allocations that require more than 85k bytes
  6. GC Heap: user allocated heap memory private to the app
  7. JIT Code Heap: memory allocated by mscoreee (Execution Engine) and the JIT compiler for managed code
  8. Process/Base Heap: interop/unmanaged allocations, native memory, etc

HTH

Dave Black
  • 7,305
  • 2
  • 52
  • 41
  • Unfortunately, there isn't a whole lot out there on all of the different heaps. Usually, the "heaps" that most people refer to or know about are the "GC Heap" and the LOH. I've found a lot by using WinDbg and analyzing memory dumps. The one place I've found some summary info about the heaps is http://msdn.microsoft.com/en-us/magazine/cc163791.aspx – Dave Black Aug 22 '12 at 13:50
  • Since there is a special heap for P/Invoke, I guess this means that if you allocate memory in C++ code when called from managed code via P/Invoke, this memory is allocated on the Stub Heap and not in the GC heap. I.e. it should be perfectly safe to allocate memory on "the heap" (Stub heap) in C++ since the GC does not touch this (and compact it). Right? But what if that heap memory is run out? Does the CLR expand it automatically I guess? – Toby999 Apr 06 '17 at 15:40
  • @DaveBlack That link is broken. Could you please share the article name and the MSDN issue (month and year)? Also, I have a related question: http://stackoverflow.com/q/43419268/303685 – Water Cooler v2 Apr 15 '17 at 19:34
  • @WaterCoolerv2 - Looks like it was May 2005 - "Drill Into .NET Framework Internals to See How the CLR Creates Runtime Objects" - via Wayback Machine https://web.archive.org/web/20080919091745/http://msdn.microsoft.com:80/en-us/magazine/cc163791.aspx – Dave Black Apr 17 '17 at 21:12
  • @DaveBlack Thank you and what a coincidence. I somehow landed on that very article in the last 24 hours via a couple of links when I searched for material that would explain the contents of the loader heap. :-) – Water Cooler v2 Apr 18 '17 at 03:10
  • I wrote-up a blog post on the different types of heaps if anyone is still interested? See http://mattwarren.org/2017/07/10/Memory-Usage-Inside-the-CLR/ – Matt Warren Aug 30 '17 at 12:03
3

You are using the new keyword to instantiate objects in two separate variables, so, this always creates new object on the heap. So the answer would be that it will always point to two separate objects.

EDIT: Static variables such as num are stored in a special area on the heap called High Frequency Heap, that is not being collected by the garbage collector etc.

TheBoyan
  • 6,802
  • 3
  • 45
  • 61
  • That being the case, num is a static field. Where would that be in the memory? – aelsheikh Dec 12 '11 at 19:21
  • That is not true. Static _variables_ are just references. The objects they refer to are normal (but rooted) objects. – SLaks Dec 12 '11 at 19:28
  • @SLaks - Yes, it's true. They're stored in a memory area called High Frequency Heap. http://stackoverflow.com/questions/4405627/high-frequency-heap – TheBoyan Dec 12 '11 at 19:33
  • @bojanskr: I don't see anything there that says that. Do you mean to say that `SomeClass.SomeField = this;` will move `this` to a different heap? I find that very hard to believe. – SLaks Dec 12 '11 at 22:24
  • The SSCLI book says that MethodTables are stored in the high-frequency heap; that has nothing to do with the values referred to by static fields. – SLaks Dec 12 '11 at 22:26
  • @SLaks - No, no. What I'm saying that static variables are "per type" variables whose value is stored in a special area of the heap(High Frequency Heap) so that they can be referenced by every instance of a class. Maybe I should clarify in my answer a little bit. – TheBoyan Dec 12 '11 at 22:28
  • That is not true. What if the same object is referenced by a static field and an instance field? – SLaks Dec 12 '11 at 22:31
  • @SLaks - It is true think about it...if a same object is referenced by a static field only the reference would be stored on the HFH so that it can be referenced by type, the object itself would be stored on the normal heap. That way both the instance and the static filed can point to the same object. – TheBoyan Dec 13 '11 at 08:48
  • Please see my answer below for Heap clarification (too many characters for a comment)... – Dave Black Aug 21 '12 at 20:47
2

From MSDN:

Only one copy of a static member exists, regardless of how many instances of the class are created.

So, because your class is non-static, you will end up with multiple instances of your class, but they will refer to the same, single, shared, static member instance.

Note: You should be VERY careful with code like the above because you can end up with multiple class instances altering the value of the shared static member which can result in unforeseen behavior, race conditions, corruptions, etc.

If your intent is for the class to be a shared singleton, then mark the class itself as static so that you only ever have one in your heap at any one time.

Rich Turner
  • 10,800
  • 1
  • 51
  • 68
1

.Net will never automatically combine similar objects.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964