Re: Perl 6 feature that scares me the most:

My vote went to Garbage Collection. I wouldn't object to a well-tuned gc built into Perl6's memory management, but current thinking seems to involve delaying all release of system resources. Timely destruction is lost by dragooning mark-and-sweep gc into the quest for correct destruction of circular chains of reference.

In On timely destruction?, Elian asked for opinions on the importance of a timely destruction guarantee. There were plenty of good answers supporting that need, but it soon became obvious that the decision had already been made.

This is the frightening part.

Without the ability to release system resources in a timely and ordered manner, Perl6 will lose Perl's greatest advantage - its ability to be useful for many purposes. Interaction with sockets, files, pipes, signals, and external processes all become subject to indeterminate delays and mysterious races. Exactly the sort of thing that makes Java so bad for such work.

I think there is a path out of this.

Keep gc for its strengths; levelling memory management overhead, and reducing memory fragmentation.
Make object destruction as timely and ordered as we can.
Civilize circular references some other way.

No, I don't have a design for that last. I'm thinking about it.

There is too much baby left in that bathwater. Don't collect it.

After Compline,
Zaxo

Comment on Re: Perl 6 feature that scares me the most:

Replies are listed 'Best First'.

Re^2: Perl 6 feature that scares me the most:
by adrianh (Chancellor) on May 31, 2003 at 09:39 UTC

Timely destruction is lost by dragooning mark-and-sweep gc into the quest for correct destruction of circular chains of reference.

While I think that correct destruction of circular references is more than enough reason to move to a decent GC system it's not the only reason.

A sane GC is also faster than reference counting for all but the most pathological of cases (you don't have to keep track of references and you get better use of your cache).

It's also much more robust. Once you have it up and running it "just works". With reference counting add one feature that forgets to bump/decrement the reference count and you're in trouble.

Personally, I think that the worries about timely release of resources and GC are overstated. I've spent a lot of time before Perl in languages with a decent GC. I can't recall a single instance of timely destruction being a problem. Arguing from personal experience is dodgy I know - but I really don't think you'll have problems. You might have to add a couple of extra techniques to handle things (e.g. block-exit handlers) - but it won't be hard or onerous..

It will be a problem for some Perl5 code running in Perl6 - not a huge amount if my code base is anything to go by. I've got much more code that has to jump though hoops to deal with circular references. The thought of throwing all of that in the bin gives me the warm fuzzies :-)

For new code there are several ways of manging timely release of resources in other ways. Perl6 has block-exit handlers, and probably other timely finalisation methods that we've not heard about yet.

For me the advantage of a decent GC more than make up for the lost of calling DESTROY when something drops out of scope.

[reply]


P is for Practical
	PerlMonks