Re: Lock-free reference counting

Juha Nieminen wrote:
Mark Wooding wrote:
To be honest, I can't say that I care greatly exactly when objects get
freed up.

Memory is not the only resource that can be reserved and freed. There
are situations where an object must free some resource (other than
memory) as soon as the object is not used anymore because even a
temporary leak of that resource might be fatal.

Yes, of course. File handles are an obvious example.

Having to manually tell the object to free the resource is obviously
error-prone (especially in languages where there may be surprising exit
points from functions, such as a thrown exception).

Some languages offer tools to help these cases, but their usage is
sometimes limited. For example, if I'm not mistaken, the C# language
offers the "using" block for this exact purpose: When the block is
exited, any object defined with the "using" will be immediately
finalized, regardless of how the block is exited. In Java I think the
"finally" block can be used for a similar purpose.

Yes.

Of course the problem with these is that they are limited to local
scope. You can't achieve a "finalize the object immediately after the
last reference to it dies" effect using those commands if the object is
shared among two different modules.

No. There is nothing to stop you from doing that in C# and Java: they give
you the choice.

Another technique which is often hard to achieve with GC'd languages
which treat objects mostly as references-to-objects is the copy-on-write
idiom. For instance, one problem is that having ghost objects outliving
the scope of their references may cause unnecessary deep-copies of the
data, even though only one live object was actually referencing the data
(and thus deep-copying it would not be necessary). Also achieving the
automatic reference counting needed for copy-on-write can be rather
laborious in itself in many such languages.

A better solution is to exploit persistence with immutable data structures.
Then you never copy anything.

If I'm not mistaken, if you want to use the copy-on-write technique in
a language like Java, the GC is actually more a hindrance than an aid.

I cannot think why that would be but I do not use Java so I am not sure.
That certainly isn't the case in OCaml/F#.

--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
.

Relevant Pages

  • Re: Basic inheritance question
    ... used 'this' in C++ and Java. ... but in Python it doesn't. ... you meant "in languages that has implicit instance reference available in methods"? ...
    (comp.lang.python)
  • Re: Basic inheritance question
    ... Old Java habits die slowly. ... No, seriously it isn't Java habits only, most other languages wouldn't ... That's not very far from what a Python method object does - ... reference to the current instance is to pass it as an argument to the ...
    (comp.lang.python)
  • Re: Lock-free reference counting
    ... Memory is not the only resource that can be reserved and freed. ... Some languages offer tools to help these cases, ... last reference to it dies" effect using those commands if the object is ...
    (comp.programming)
  • Re: How come value types are not true objects?
    ... Java has exactly the same distinction between value types and reference ... Yes, Java has wrapper classes. ... > int GetObj{return Num;} ... > that Java and other modern languages don't seem to have this problem. ...
    (microsoft.public.dotnet.framework)
  • Re: Finding the instance reference of an object
    ... languages also offer a by-reference mode that Python andJavado not). ... course most Java programmers would have a hard time taking this claim ... Like most pure object-oriented languages, ... only the reference is copied. ...
    (comp.lang.python)