 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 9:58 AM, clipka wrote:
> It is a problem only as long as you tie object destruction to reclaiming
> of memory.
I think I probably just explained it poorly, the example I was imagining
was pretty much identical to what Warp pointed out.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> 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:
- Resolve the location of all used objects by looking for references
to those objects in the program data.
- The size of the objects can be resolved from the reference type and/or
a virtual table pointed by the objects themselves.
- Sort the addresses of the objects.
- Compact all the objects by moving them towards the beginning of the
heap so that no free space is left between them.
- Update the "free memory starts from here" pointer to the end of the
last object relocated this way.
(Of course an actual GC is much, much more complicated than that in
order to make it actually efficient.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.03.2012 18:07, schrieb clipka:
> Am 14.03.2012 17:57, schrieb Warp:
>
>>>> And btw, cyclic references are not the only problematic situation with
>>>> reference counting. There are cases where objects may be deleted too
>>>> early,
>>>> while there's still code using them.
>>
>>> I can't think of any reason why that could possibly happen, provided
>>> that the reference counting is implemented in a thread-safe manner.
>>
>> Module A has a reference-counting smart pointer pointing to an object B.
>>
>> A member function of that object B calls a function of module A. Said
>> function of A drops the reference to object B. Since it was the only
>> reference pointing to it, the object B gets deleted. When the function
>> in A ends, the execution returns to the member function of B, which now
>> operates on a deleted object. Undefined behavior ensues.
>>
>> Yes, that *can* happen.
>
> Hm... you do have a point there.
Then again, how would any other GC prevent this kind of thing happening?
As soon as A drops the reference to B, the latter isn't referenced
anymore, so if at this moment the GC happens to kick in you're still in
for trouble. Except that now your error is even more sporadic in nature
and therefore even more difficult to hunt down.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> > Module A has a reference-counting smart pointer pointing to an object B.
> >
> > A member function of that object B calls a function of module A. Said
> > function of A drops the reference to object B. Since it was the only
> > reference pointing to it, the object B gets deleted. When the function
> > in A ends, the execution returns to the member function of B, which now
> > operates on a deleted object. Undefined behavior ensues.
> >
> > Yes, that *can* happen.
> Hm... you do have a point there.
I learned it the hard way. Yes, it happened to me in an actual project,
and I didn't know of this problem before that.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/14/2012 10:12 AM, Warp wrote:
> I learned it the hard way. Yes, it happened to me in an actual project,
> and I didn't know of this problem before that.
Heh, me too. It was quite a perplexing error at first.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
