If you destroy a List of Class objects...

Questions & Answers
1

Sorry for another lame-ass Unityscript question. (Where’s the “idiot Unityscript questions” section of the forum??)

If you have a Unityscript struct,

class Concepts extends System.ValueType
    {  }

and then you do this,

var x:List.<Concepts> = new List.<Concepts>;
for ( i=1;  ++i<1000000;  )
    x.Add( new Concept() );

you now have a million of the STRUCT Things. If you then do this

x = new List.<Concepts>;  // point "B"

All one million of the structs go away.

So, thats all very well. Question: if you have a Unityscript Class (NOT a struct),

class Abstractions //  SIC .. a class, not a struct idiom
    {  }

and then you do this,

var y:List.<Abstractions> = new List.<Abstractions>;
for ( i=1;  ++i<1000000;  )
    y.Add( new Abstractions() );

you now have a million of the CLASS Things. If you then do this

y = new List.<Abstractions>; // point "D"

WHAT HAPPENS?

ie: do you have to eliminate them all manually first (in some way)?

FTR. is the answer exactly the same if you use a natural array?? As a further curiosity, Javascript gurus, is it the same in “standard” Javascript? Thank you for your attention to this lame Unityscript question…cheers

Mike …

in view of your superb explanation. {It didn’t even explicitly occur to me it’s a GC environment, of course it is - thanks!}

My questions to you,

(ONE) at point “B” (see ‘comments’ in the example code) when I make x point to a new List, DO I HAVE TO / SHOULD I DO ANYTHING regarding the million Concept structs which the old List at x pointed to?

and then,

(TWO!) at point “D” when I point x to a new List, same question … should I / do I have to do anything to the old million Abstractions classes ?

Thank you!

The further question, 1B and 2B:

in fact, IS THERE a way to indicate to the GC system in this environment, that I particularly don’t need the million structs (or classes) any more?

Or is that meaningless, it just counts references itself, does so safely, and that’s it ?

On some systems there is often a concept like say a “pool” of references, you can urge the GC system to empty out the pool, when you feel it is a good idea as a human.

Final further question: and in view of all that, is there really any difference between using either structs or classes in the example given? Does it decrement the GC once more, or something, for structs, or?? they’re just the same and there’s no issue to worry about there?

Thank you for being an expert !!

Buy this!

1231-CLR.jpg

2

Actually in neither circumstance is the memory actually freed immediately - it’s just available for Garbage Collection by .NET. UnityScript is different to JavaScript in this regard - but how actually varies by JavaScript implementation.

The Garbage Collector runs many times during execution - using a thing called Generations. Generation 0 is collected every time it fills up - and it fills up quick because its only around 256KB - the Garbage Collector tests for reachability of objects - i.e. does something have a reference to that object, and if it does, does the thing that has a reference have a reference to it etc etc etc

Anything that has a reference at the time of collection moves to the next higher Generation - Generation 1 is about 1MB and when it fills up then it is collected. The worst nightmare for a GC system is short lived objects getting moved to higher generations and it’s that which causes Generations that aren’t tiny to be collected and the game to glitch.

So in your example, there is no need to destroy the class when it becomes unreachable. Each element will be collected when its generation is collected. That might not be all at the same time of course. Presuming things that derive from ValueType are held contiguously in memory - the difference is that the structs held in an array would cause the entire array to be collected at the same time, because it is effectively one thing.

Lists grow as you add things to them, so the actual slots that hold the references to classes will be collected many times as the system decides on the next size of block to hold them in.