"The problem is this case is a register with the value, not a memory location"

I don t understand what a register is :( Could you give me an example? And maybe Your workaround for that?

greetings

Matthias Thurau Wrote:

> "The problem is this case is a register with the value, not a memory location"
> 
> I don t understand what a register is :( Could you give me an example? And maybe Your workaround for that?
> 
> greetings

A register is a small storage available to the cpu to make computation. http://en.wikipedia.org/wiki/Processor_register

However I doubt that Sean's assumption is valid in this case. I've modified the original testcase to call

{ MyClass A =    new MyClass(); }

up to a couple tens of THOUSAND times.

Whereas the scoped class is destroyed on scope exit, the destructor of the embedded object is only called at program termination (as described). Collect as
no effect on them, no matter how many instances are created.

That would be a lot of registers!

Some other things I have noticed:

* Without scope attribute, all instances of both classes are destroyed on collect. No problem.

* With the scope attribute, embedded instances are destroyed in reverse order of creation, by group of 256.

Sub_Destructor2 255
...
Sub_Destructor2 0
Sub_Destructor2 511
...
Sub_Destructor2 256
..

This GC behavior is stranger than usual...

(using Phobos.)

guslay wrote:
> Matthias Thurau Wrote:
> 
>> "The problem is this case is a register with the value, not
>> a memory location"
>>
>> I don t understand what a register is :( Could you give me an example? And maybe Your workaround for that?
>>
>> greetings
> 
> A register is a small storage available to the cpu to make computation. http://en.wikipedia.org/wiki/Processor_register
> 
> However I doubt that Sean's assumption is valid in this case. I've modified the original testcase to call
> 
> { MyClass A =    new MyClass(); }
> 
> up to a couple tens of THOUSAND times.
> 
> Whereas the scoped class is destroyed on scope exit, the destructor of the embedded object is only called at program termination (as described). Collect as
> no effect on them, no matter how many instances are created.

Oops.  My comment about registers referred to the GC not collecting the most recently constructed object which simply went out of scope. Objects created with the "scope" attribute are entirely different.  In that case, the "scope" object is deleted when scope exits, but no objects it references are deleted.  This is by design, and I addressed it in another post in this thread.


Sean

Sean Kelly Wrote:

> guslay wrote:
> > However I doubt that Sean's assumption is valid in this case. I've modified the original testcase to call
> > 
> > { MyClass A =    new MyClass(); }
> > 
> > up to a couple tens of THOUSAND times.
> > 
> > Whereas the scoped class is destroyed on scope exit, the destructor of the embedded object is only called at program termination (as described). Collect as
> > no effect on them, no matter how many instances are created.
> 
> Oops.  My comment about registers referred to the GC not collecting the most recently constructed object which simply went out of scope. Objects created with the "scope" attribute are entirely different.  In that case, the "scope" object is deleted when scope exits, but no objects it references are deleted.  This is by design, and I addressed it in another post in this thread.


I think that the point of the original post is getting lost.  After having scope variable(s) go out of focus (and get deallocated), a call to full collect is done.  The issue was that full collect did not collect the objects allocated by the scope objects, even though there was no references to them.

Jason House wrote:
> Sean Kelly Wrote:
> 
>> guslay wrote:
>>> However I doubt that Sean's assumption is valid in this case. I've modified the original testcase to call
>>>
>>> { MyClass A =    new MyClass(); }
>>>
>>> up to a couple tens of THOUSAND times.
>>>
>>> Whereas the scoped class is destroyed on scope exit, the destructor of the embedded object is only called at program termination (as described). Collect as
>>> no effect on them, no matter how many instances are created.
>> Oops.  My comment about registers referred to the GC not collecting the most recently constructed object which simply went out of scope. Objects created with the "scope" attribute are entirely different.  In that case, the "scope" object is deleted when scope exits, but no objects it references are deleted.  This is by design, and I addressed it in another post in this thread.
> 
> 
> I think that the point of the original post is getting lost.  After having scope variable(s) go out of focus (and get deallocated), a call to full collect is done.  The issue was that full collect did not collect the objects allocated by the scope objects, even though there was no references to them.  

Right.  This related to my comment about registers above.


Sean