cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [Design] ContainerManager is under fire--let's find the best resolution
Date Thu, 06 Jun 2002 22:18:27 GMT
Gosh, I forgot how strident can become talking about high level
abstractions... remind me of the good old days when we were discussing
what later became known as Avalon and Pier and I got such a huge fight
for a simple method.

ihihih, discussing such high-level abstractions can get really nasty
ego-wise :)

Berin Loritsch wrote:
> 
> > From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> >
> > > From: Berin Loritsch [mailto:bloritsch@apache.org]

blah blah blah

Let's clear up the table.

Berin is proposing a better CM and I like it more than what Avalon 4
has. First of all, it removes that stupid "pass non-exceptional info
with exceptions" design pattern.

Ah, BTW, there are *tons* of places where this happens in Avalon,
please, make sure the above anti-pattern is removed from Avalon 5.

Then it removes the need for that hacky ComponentSelector, unifying
approaches.

Anyway, despite a few issues I'm having (I don't see why we should
return an Object instead of a Component. That's a component selector,
not an object selector. There is the Class object for that!) I see it as
a step forward.


The problem is garbage collection of components.

                                   - o -

WARNING: radical changes ahead, this is not for the faint-hearted! YOU
HAVE BEEN WARNED!

Let's make one step back: what is an avalon component?

I'm pretty sure that everybody has a different idea on what this really
is, but here is my personal one: 

  an avalon components is the implementation of a functional description

[so far, is nothing different from a normal class implementing an
interface]

  and exposes behavioral modifiers

This is the difference between an Avalon component and a java class
implementing an interface: the way the class is created.

[the other differences are functional, not conceptual]

In Java, the only way to modify how a class is constructed is to call a
different constructor method. Unfortunately, java doesn't define
"construction prototypes" but only 'functional prototypes' (with
interfaces).

This left the original Avalon designers with one radical solution:
deprecate the use of constructors and create a totally different
construction lifecycle.

First, we thought about creating a ComponentFactory, something like

 public class ComponentFactory {
    Component createComponent(String componentName);
 }

but soon we realized that the ability to separate the concern of
creation from that of use, we could simply create pools of pre-created
objects. So, in that case, createComponent() was a bad name and Factory
too limiting.

This lead to the concept of a ComponentManager, the 'director' of the
'play', where each actor asks the director to indicate what person
performs a particular role in the play, in order to be able to
communicate with it.

The CM is also able to 'instruct' a new actor to perform a particular
role. So, from a design pattern point of view, "Manager extends
Factory".

We didn't think about role collisions: blinded by the 'play metaphor',
we thought that there was no need, on stage, for two actors acting the
same role with dressed up in different colors. On later thought, this is
not true: it is the rule that important carachters in the play has a
'backup'. In that case, an actor might ask not only the role played, but
also the 'hint' (official/backup) to obtain the reference to the other
actor.

So, it makes perfect sense to merge the two aspects into a single CM.

So far so good.

                                   - o -

Two steps back, now.

Before the introduction of automatic garbage collection, everybody
allocated memory, used it and freed it when it was not needed. Failing
to do the last part provided those infamous 'memory leaks' that almost
all programs in the world suffer.

In more abstracted languages where you don't have direct access to the
memory, you don't allocate it directly, but you create an functional
entity (object, for example), you use it, then you dispose it.

This is less error prone because it's more abstract, but still requires
people to know what they are doing and don't forget to dispose those
objects which aren't needed.

Enter garbage collection: at the price of a system overhead, the
programmer is released from the responsibility to provide explicit
disposal for the objects he creates.

You know what? I'm starting to think that the java GC is a gigantic
mistake. Why? simple, it's useless.

A GC continue to skeep thru your object space to look for 'detached'
objects. That's a great implementation, but what if I forgot to 'detach'
those objects?

If GC was that effective, why Java programs leak memory anyway?

Some people believe that Java is inherently safer than C because it has
garbage collection that prevents people from shooting themselves in the
foot with direct pointers to memory.

WRONG!

It's the absence of pointers that make Java safer, not the capability of
the VM to clean up your mess for you. It can't! It can't be smarter than
you no matter how hard you try! 

If I was to rewrite java from scratch I would simply make that stupid
and utterly useless

 Object.finalize()

method active and native instead of passive and empty! 

So, instead of doing

 HashMap map = new HashMap();
 map.add("a","1");
 map.add("b","2");

 ...

 map = null // let's make it ready for GC

you call your stinking

 map.finalize();

[much better names would be destroy(), dispose(), cleanup()]

that invalidates it and turns 'map' into a null and recursively
invalidates all those objects that are not bound to any other object
(this can be done asynchronously, but it's a VM implementation detail)

                                   - o -

Berin points out that people might forget to dispose thier components,
thus producing leaks. If made automatic, component GC could eliminate
this problem entirely and make it easier to use Avalon.

I agree on the intention but I question the effectiveness of the
approach: Java has shown that GC doesn't eliminate memory leaks because
the program has no way to interact with the garbage generation strategy
of the JVM.

This was somewhat changed with WeakReferences: the GC treats objects and
weakobjects differently. Unfortunately, these are hardcoded GC
strategies and there is no way to create ThreadGroupObjects or other
similar GC strategy aspects.

It's evident: the java architects didn't bother much at making object
construction strategies more aspect oriented, and they did the same with
object destruction.

So, from an elegance point of view, it makes perfect sense, for Avalon,
to provide aspect-oriented construction strategies *and* aspect-oriented
destruction strategies.

Just like it's the component manager's concern to construct your
component the way the component was instructed to (depending on the
interfaces it implements), similarely, it should be the component
manager's concern (or some proxy slave, that's an implementation detail)
to dispose the component, depending on the disposing strategy that the
component implements.

                                    - o -

The only concern I have is the fact that the dispose() method for the CM
might still be required for all those cases where the strategy might not
apply correctly, or for those cases where a strategy would need native
access to the JVM to fully obtain enough information to perform.

I think that even if we come up with a transparent component disposable
strategy framework, the dispose() method in the CM woudn't hurt and
would keep everybody happy.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message