clipka <ano### [at] anonymousorg> wrote:
> Then again, how would any other GC prevent this kind of thing happening?

  A GC keeps track of *all* the references that are pointing to an object,
including the 'this' pointer (or whatever the equivalent is in any given
language).

  You could avoid this problem in a reference-counted scenario by
incrementing the reference count in the beginning of the function and
decrementing it when exiting the function, but that's burdensome and
makes member functions less efficient (especially if they are supposed
to be fast).

-- 
                                                          - Warp

Post a reply to this message

Am 14.03.2012 18:09, schrieb Warp:
> clipka<ano### [at] anonymousorg>  wrote:
>> If a GC implementation doesn't track free blocks, how is it ever going
>> to re-allocate them to anything?
>
>    A naive implementation of that would be:
> [...]


Well, I wasn't actually considering approaches that would be 
prohibitively inefficient :-P

Post a reply to this message

Am 14.03.2012 18:16, schrieb Warp:
> clipka<ano### [at] anonymousorg>  wrote:
>> Then again, how would any other GC prevent this kind of thing happening?
>
>    A GC keeps track of *all* the references that are pointing to an object,
> including the 'this' pointer (or whatever the equivalent is in any given
> language).
>
>    You could avoid this problem in a reference-counted scenario by
> incrementing the reference count in the beginning of the function and
> decrementing it when exiting the function, but that's burdensome and
> makes member functions less efficient (especially if they are supposed
> to be fast).

But doesn't the "this-pointer tracking" in a reference-tracking GC 
approach incur approximately that very same penalty?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> But doesn't the "this-pointer tracking" in a reference-tracking GC 
> approach incur approximately that very same penalty?

  Efficient GC algorithms are extremely complicated and I don't know in
detail how they work, but AFAIK they do not keep track of all references
all the time, but only periodically. That means that when a method is
called, it doesn't necessarily incur any penalty at all in terms of
memory management.

  (This means that objects are not destroyed immediately when the last
reference to them disappears. Only when the GC algorithm determines at
some point that no reference exists to an object, will it mark to be
eventually removed.)

-- 
                                                          - Warp

Post a reply to this message

Invisible escreveu:
> On 14/03/2012 04:53 AM, clipka wrote:
>> Am 13.03.2012 21:37, schrieb Orchid Win7 v1:
>>
>>> Wait - there are open-source Java libs now?
>>>
>>> (Last time I looked at Java, all anyone ever used it for was pointless
>>> Tic-Tac-Toe applets. Nobody ever wrote actual large applications with
>>> it, just small toy examples.)
>>
>> You've never heard of Java enterprise application servers, have you?
> 
> I've heard of them - but I have no idea what the hell they are. Last 
> time I checked, "enterprise" refers either to NCC-1701-D, a galaxy-class 
> starship of the United Federation of Planets, or to a piece of software 
> which is pointlessly over-engineered, over-complex, over-priced, and 
> sold by pushy over-paid salesmen in bad suits.

it's everywhere, Andrew.  Kinda like electricity: you just notice it 
when it goes down (and a huge call stack fills your browser).

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

Invisible escreveu:
> Backwards compatibility is pretty evil, eh? ;-)

haskell still to get its own historic warts... :)

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

On 14/03/2012 17:49, clipka wrote:
> Am 14.03.2012 18:09, schrieb Warp:
>> clipka<ano### [at] anonymousorg> wrote:
>>> If a GC implementation doesn't track free blocks, how is it ever going
>>> to re-allocate them to anything?
>>
>> A naive implementation of that would be:
>> [...]
>
>
> Well, I wasn't actually considering approaches that would be
> prohibitively inefficient :-P

That's actually how Haskell's GC works. :-P

(Or rather, it is if you select 1-space. The default is 2-space. In 
other words, it allocates twice as much RAM as it actually needs. When 
one half fills, it copies everything to the other half. More RAM, but 
less processor time...)

Post a reply to this message

On 14/03/2012 16:51, Warp wrote:
> Invisible<voi### [at] devnull>  wrote:
>> The GC engine needs to know quite a bit about the objects it's scanning
>> - how big they are, where their pointer fields are, etc.
>
>    Exactly how does the GC engine know how large a block of allocated
> memory is? Where is this information stored?

Usually the object's class tells you that. You already have a vtable or 
similar structure. (At least, you do in languages where /everything/ is 
dynamically bound by default.)

>    Also, if objects are transparently movable in memory without breaking
> the references pointing to them, that means that in addition to the
> reference the actual raw memory address of the object has to also be
> stored somewhere. Where is this information stored?

Depends on the implementation.

Smalltalk does it by adding a layer of indirection. The address of every 
object in the system is held in a giant "object table". All objects are 
referred to be object IDs, which are merely indices into this table. To 
move an object, merely update its object table entry. (You can also 
store auxiliary information here - e.g., if you wanted to /lock/ the 
object while it's being moved.)

How Haskell does it is to copy each object from its old location to its 
new location, and then overwrite the old copy with a "hey, this is where 
I moved this object to" reference. The GC engine then uses that to 
update any references in other objects as it finds them.

>    You can't avoid bookkeeping when you are allocating blocks of variable
> size.

Sure. At a minimum, you need to know the size of those blocks. 
Realistically, you also need to know what they contain, or you can't 
follow pointers. You probably need to know a little other stuff too.

Most of this information is per-class rather than per-object, however.

Post a reply to this message

On 14/03/2012 19:47, nemesis wrote:
> Invisible escreveu:
>> Backwards compatibility is pretty evil, eh? ;-)
>
> haskell still to get its own historic warts... :)

Sadly, yes.

Although it /does/ have fewer than most languages. Then again, there's 
less of it to start with, so I guess it would do.

Post a reply to this message

On 14/03/2012 18:58, nemesis wrote:

> it's everywhere, Andrew. Kinda like electricity: you just notice it when
> it goes down (and a huge call stack fills your browser).

Do you want to know... what... it... is?

The Matrix is everywhere. It is all around us. Even here, in this very 
room. You can... feel it. When you walk across the street. When you go 
to church. When you pay your taxes.

(Wait, what were we talking about?)

Post a reply to this message