Immutable and Transient Objects and GC?

Immutable and Transient Objects and GC?

[Dimonax]

I'm researching the use of Immutable and Transient data structures in 
regards to Concurrent Garbage collection in Ada.

While my focus for the moment is on Garbage Collection, these kinds of 
data structures look useful for solving a lot of Concurrent programming 
issues.

An Immutable Object, conceptually, is pretty clear. I'm curious as to 
what methods you guys might have used to handle them.

Transient Objects, as a formal data type, might be a bit more 
challenging. I'd like a Transient Object to behave thusly....
It's created once. It exists until it is accessed one time and one time 
only, at which point it's storage is either re-initialized or reclaimed 
by the system.

I have some ideas on how this might work. But I'm still dancing around, 
trying to figure out how to do it well.

Tips and pointers?

Freejack
aka
Diogenese

Re: Immutable and Transient Objects and GC?

[Maciej Sobczak]

On 18 Mar, 21:07, Dimonax <dimo...@nospam.net> wrote:

> An Immutable Object, conceptually, is pretty clear.

Even though there is a bit of hype around immutable objects recently,
related to the hopes that this automagically solves concurrency
problems (which ones, really?), I do not think that it can become a
mainstream approach in languages like Ada.
The problem is that Ada is really a value-oriented language (and not a
reference-oriented one) and there are lots of fundamental language
constructs that promote or even require mutability: 'out' and 'in out'
parameter modes are just examples. Also, there is a strong culture of
avoiding, or at least not overusing, dynamic memory allocation and
this requires mutable state for recycling objects.
In other words, mutability is part of the language spirit.

In addition and just IMHO, immutability cannot be a solution for
anything, because it distorts what should be a natural design of a
given program. What I mean by natural is that (im)mutability of any
given object should come out from the main problem analysis and not
from elsewhere - trying to solve whatever concurrency issues you have
is that "elsewhere" because it has nothing to do with what the given
object represents.
In other words, if the given object *happens* to be immutable as a
result of the problem analysis and this fact can help with
concurrency, then it is a worthy coincidence; but when immutability of
objects is *imposed* in order to solve some unrelated concurrency (or
other) issues, then it is just a design distortion.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Immutable and Transient Objects and GC?

[Dimonax]

On Wed, 18 Mar 2009 14:32:55 -0700, Maciej Sobczak wrote:

> In other words, if the given object *happens* to be immutable as a
> result of the problem analysis and this fact can help with concurrency,
> then it is a worthy coincidence; but when immutability of objects is
> *imposed* in order to solve some unrelated concurrency (or other)
> issues, then it is just a design distortion.

Good point.

However, what about Transient Objects, which seem to be pretty much the 
inverse of Immutable Objects. Ala Forth

They make sense for a lot of data structures, particulary sequential 
structures like stacks, queues, etc...
Thier property of being immediately freed upon thier first access means 
that I can make a lot of optimizations that arent available to regular 
data types.

Freejack

Re: Immutable and Transient Objects and GC?

[Maciej Sobczak]

On 18 Mar, 22:50, Dimonax <dimo...@nospam.net> wrote:

> Good point.
>
> However, what about Transient Objects, which seem to be pretty much the
> inverse of Immutable Objects. Ala Forth

I have no idea what that is. Could you please elaborate a bit?

> They make sense for a lot of data structures, particulary sequential
> structures like stacks, queues, etc...

Could you please give more details? I have seen and implemented these
structures but I still do not know what is Transient Object.

--
Maciej Sobczak * www.msobczak.com * www.inspirel.com

Database Access Library for Ada: www.inspirel.com/soci-ada

Re: Immutable and Transient Objects and GC?

[Dimonax]

On Thu, 19 Mar 2009 01:14:45 -0700, Maciej Sobczak wrote:

> On 18 Mar, 22:50, Dimonax <dimo...@nospam.net> wrote:
 
> I have no idea what that is. Could you please elaborate a bit?
 
> Could you please give more details? I have seen and implemented these
> structures but I still do not know what is Transient Object.

To quote http://www.simonbingham.me.uk/2009/02/object-orientated-
programming-oop.html
"Transient

Transient objects are not stored in shared scopes and require separate 
instances to provide different behaviour and data. Transient objects 
usually represent Domain Objects (e.g. a User or a Product)".

This is what they would be in an OOP paradigm. However the concept is 
much more general. If you've ever worked with a Forth machine or a 
Concatenative Programming Language(where probably 95% of all the data is 
Transient) you'll know exactly what I mean.

Trasient data and objects exist solely for the purpose of being consumed 
again.
Since thier always being consumed, storing them in memory usually doesnt 
cost much because there are rarely enough of them to be a burden on the 
system.

Freejack

Re: Immutable and Transient Objects and GC?

[Dmitry A. Kazakov]

On Thu, 19 Mar 2009 19:23:38 GMT, Dimonax wrote:

> Trasient data and objects exist solely for the purpose of being consumed 
> again.

It is not clear why they should have a distinct type. Ada per design is
such that the object type does not depend on the way its scope is managed.
This allows the compiler to create temporal or what you call "transient"
objects as necessary, transparently to the type semantics. For example,
in-out parameters can be copied-in and -out, so that the program would deal
with a "transient" object without knowing it. It is important not to know,
because in other places the compiler could choose by reference parameter
passing for the same type.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de