Re: Simple question on memory behavior

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Tyson Brown (tyson.brown.REM0VE_at_sbcglobal.net)
Date: 05/10/04

  • Next message: Junfeng Zhang: "RE: Severe limitation for IE-hosted .NET controls (classid is truncated to 128 chars)" 
    Date: Mon, 10 May 2004 16:11:04 -0700

    Brian, thanks for responding.

    > 1. (a) To be specific, the object pointed to by tmpPage can be collected
    > after line 5, but that object points to another object (PageName). That has
    > a second (at least) reference to it via IStickAround.CurrentPageName and
    > thus the string would not be collected.

    The string object itself will not be collected, but everything else about that tmpPage object will be collected as long as I mark it as null and there aren't any other root pointers to any of the other ref properties, right? Objects (tmpPage) can be destroyed and cleaned up even if a ref value created inside the object (tmpPage.PageName = "abc") still exists because of another reference (IStickAround.CurrentPageName = tmpPage.PageName)... Just need to make sure I understand it.

    In my application I have *five* objects I populate based on a series of URL information to tell my app about the user, where they are in the system, what they can see, etc. By the time I get to actually process the more complex code (user controls), I have already generated these five classes and are finished with them, EXCEPT for the limited values that the user controls need (PageName, PageId, ControlAlias, ControlId, ClubId, ClubName, etc.)

    I was just worried that since I am assigning a couple properties of each object to IStickAround, it would keep all five objects around while all the user controls processed, which would be bad under load. But if I am understand it correctly, I think I'll be OK.

    > As a side note: Strings are a special case because they are immutable and
    > the CLR takes advantage of this fact. It keeps a "global string repository",
    > so code such as:
    >> Foo a = new Foo();
    > Foo b = new Foo();
    > a.MyName = "abc";
    > b.MyName = "abc";
    >> actually results in just 3 objects. Even though "abc" seems like two string
    > objects, a.MyName ends up pointing to the same memory as b.MyName.

    Oooh.. nice to know.
         
    > 2. Not sure I fully understand the question. If PageItem has properties,
    > then they must be individually assigned. CopyTo() is typically an array copy
    > method provided by objects, but that isn't the same as properties...

    I was thinking of the System.String's CopyTo() method to "copy" PageName to CurrentPageName, so that tmpPage would make sure and be gone before the heavy processing starts. But that was before understand how it works.

    Thanks again for all the information, everyone!

    Tyson

  • Next message: Junfeng Zhang: "RE: Severe limitation for IE-hosted .NET controls (classid is truncated to 128 chars)"

    Relevant Pages

    • Re: Confused about casting.
      ... each Match and load them into a String[]? ... That's not as convenient as CopyTo, ... pass in against the Match objects in the array - so I would bet you always ... The cast only converts the String reference to an Object reference - it does ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: arraylist copy
      ... Then what is the difference between CopyTo and Clone? ... >reference, than they grew apart. ... >A copyto makes a copy of the values in a one dimensional array. ...
      (microsoft.public.dotnet.languages.vb)
    • Re: arraylist copy
      ... Then what is the difference between CopyTo and Clone? ... > a reference, than they grew apart. ... > A copyto makes a copy of the values in a one dimensional array. ...
      (microsoft.public.dotnet.languages.vb)
    • Confused about casting.
      ... I get the feeling that I am missing something with regards to casting. ... If I CopyTo to a string array ...
      (microsoft.public.dotnet.languages.csharp)