RE: [9fans] Re: advantages of limbo

RE: [9fans] Re: advantages of limbo

[YAMANASHI Takeshi]

On Wed Mar  3 16:34:28 JST 2004, Tiit Lankots wrote:
> (2) Therefore, no-one uses Plan 9.

no, no.  I meant none *positively* uses Plan 9 a lot. :)

ex.
cpu% ps | grep none
none             31    0:00   0:13    1384K Open     httpd
none             33    0:00   0:04     156K Sleep    listen
none             36    0:01   0:05     156K Await    listen
none             41    0:00   0:00     156K Open     listen
none             42    0:00   0:00     156K Open     listen
none             43    0:00   0:00     156K Open     listen
none             44    0:00   0:00     156K Open     listen
none             45    0:00   0:00     156K Open     listen
none             46    0:00   0:00     156K Open     listen
none             47    0:00   0:00     156K Open     listen
none             48    0:00   0:00     156K Open     listen
none             49    0:00   0:00     156K Open     listen
none             50    0:00   0:03     156K Open     listen
none             51    0:00   0:00     156K Open     listen
none             52    0:00   0:00     156K Open     listen
none             53    0:00   0:00     156K Open     listen
none             54    0:00   0:00     156K Open     listen
none             55    0:00   0:00     156K Open     listen
none          30737    0:00   0:00     120K Pread    tcp17010
none          30748    0:00   0:00     184K Rendez   exportfs
-- 

Re: [9fans] Re: advantages of limbo

[boyd, rounin]

> no, no.  I meant none *positively* uses Plan 9 a lot. :)

i wondered if there was a pun in there ;)

Re: [9fans] Re: advantages of limbo

[Kenji Okamoto]

> or just hoping to steal some ideas. ☺

Ohh--o!
I wanted to say leaning and stealing is a quite different
thing, even no resemble to each other...

Kenji

Re: [9fans] Re: advantages of limbo

[Kenji Okamoto]

>> In fact, no-one uses Plan 9, right?
> 
> Surely, none uses Plan 9 a lot.

or just hoping to steal some ideas. ☺

Kenji

Re: [9fans] Re: advantages of limbo

[YAMANASHI Takeshi]

> In fact, no-one uses Plan 9, right?

Surely, none uses Plan 9 a lot.
-- 

Re: [9fans] Re: advantages of limbo

[ron minnich]

On Tue, 2 Mar 2004 matt@proweb.co.uk wrote:

> No offense to anyone, and I'm guilty too, but Java, do we really care?

I don't. I hate java.

ron

Re: [9fans] Re: advantages of limbo

[matt]

No offense to anyone, and I'm guilty too, but Java, do we really care?
It's so OT

m

Re: [9fans] Re: advantages of limbo

[Andrew Simmons]

>
>Class Thread is not a part of the language. 'synchronized'
>is. What's wrong with Java synchronization? Can you please
>bring an example in Java and limbo where Java's synchronization
>is bad while limbo's approach is right?

Brinch Hansen's paper "Java's Insecure Parallelism" is worth a read. There 
have been at least a couple of attempts at welding a CSP style framework on 
top of Java threads  - eg:

http://www.cs.kent.ac.uk/projects/ofa/jcsp/

but the syntax looks fairly brutal.

Re: [9fans] Re: advantages of limbo

[rog]

> > ... Mr Nemo
>
> mr no-one [latin], right?

just call him captain.

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 25 bytes --]

But only while onboard.

[-- Attachment #2: Type: message/rfc822, Size: 1695 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: advantages of limbo
Date: Tue, 2 Mar 2004 19:10:48 0000
Message-ID: <543e651e9d4add46d78ca6f47dd52193@vitanuova.com>

> > ... Mr Nemo
>
> mr no-one [latin], right?

just call him captain.

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 70 bytes --]

Right.
I'm glad you know.
In fact, no-one uses Plan 9, right?
☺

[-- Attachment #2: Type: message/rfc822, Size: 1967 bytes --]

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: advantages of limbo
Date: Tue, 2 Mar 2004 19:38:27 +0100
Message-ID: <019d01c40085$8ed5e790$67844051@SOMA>

> ... Mr Nemo

mr no-one [latin], right?

Re: [9fans] Re: advantages of limbo

[boyd, rounin]

> ... Mr Nemo

mr no-one [latin], right?

Re: [9fans] Re: advantages of limbo

[andrey mirtchovski]

>>> The Inferno/Java paper (somewhere on the web site, but likely also in
>>> the Plan 9 distribution) covers it rather nicely.
>> 
>> Google brings inexistent link.
>> 
> Hm, maybe forsyth can help you with a copy, I'd have to search for one
> myself.  If you want to wait, I must have one on the old Inferno CD.
> 

maybe this paper would help too:

	http://cm.bell-labs.com/cm/cs/who/bwk/interps/pap.html

"Timing Trials and Trials of Timing: Experiments with Scripting and
User-Interface Languages"

contains comparisons between Awk, Perl, Tcl/Tk, Java, VB and Limbo.
it's rather old but worth a read, especially when nowadays you see
people benchmarking a language by making it run a multiplication a few
hundred times and calling it quits.

plumb-ready link:

	http://cm.bell-labs.com/cm/cs/who/bwk/interps/paper.ps

andrey

Re: [9fans] Re: advantages of limbo

[C H Forsyth]

>> Java has closures?

>Of course it does.

sorry, once i worked through that i realised we
weren't talking about the same thing.  my fault.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> > > Yet [Java] is more powerful in expressing algorithms. Things like closures
> > > or message polymorphism are natural and easy to express in Java, while
> >
> > Java has closures?
> >
>
> Of course it does.
>
> interface Appl {Object f(Object o);}
>
> interface List {void foreach(Appl a);}
>
> class test {
>   void do(List l) {

But I am convinced that cheap threads are good for 
the purpose.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> From: C H Forsyth <forsyth@vitanuova.com>
>
> > Yet [Java] is more powerful in expressing algorithms. Things like closures
> > or message polymorphism are natural and easy to express in Java, while
>
> Java has closures?
>

Of course it does.

interface Appl {Object f(Object o);}

interface List {void foreach(Appl a);}

class test {
  void do(List l) {
    String s="element: ";
    l.foreach(new Appl() {
      String t=s;
      Object f(Object o) {
	System.out.println(t+o);
      }
    });
  }
}

Untested, but the idea is simple: foreach is passed a dynamic
closure with variable s inherited from the context.

t=s is to show how a local binding can be explicitely created,
one could simply write

    l.foreach(new Appl() {
      Object f(Object o) {
	System.out.println(s+o);
      }
...

David

Re: [9fans] Re: advantages of limbo

[C H Forsyth]

> Yet [Java] is more powerful in expressing algorithms. Things like closures
> or message polymorphism are natural and easy to express in Java, while

Java has closures?

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> re: closures: cheap and easy threads provide a more than adequate
> re: message polymorphism.

Rog,

thanks a lot. Very informative. I am motivated.

David

Re: [9fans] Re: advantages of limbo

[rog]

> Yet [Java] is more powerful in expressing algorithms. Things like closures
> or message polymorphism are natural and easy to express in Java, while
> either not possible or inconvenient in limbo.

re: closures: cheap and easy threads provide a more than adequate
substitute in many cases.  a channel can represent a connection to a
remote procedure with its attached data.

for instance, a trivial example:

getop(s: string): chan of (string, chan of string)
{
	c := chan of (string, chan of string);
	spawn append(s, c);
	return c;
}

append(s: string, c: chan of (string, chan of string))
{
	for(;;){
		(t, reply) := <-c;
		reply <-= s + t;
	}
}

in this example, the channel returned by getop(s)
is functionally equivalent to λt.(s + t).
the generic operator would look like:

op(s: string, c: chan of (string, chan of string)): string
{
	reply := chan of string;
	c <-= (s, reply);
	return <-reply;
}

of course in this case the amount of code compared with its actual
function is considerable, but for less trivial applications this is
often viable (moreover, it's considerably more powerful, as the
channel represents an ongoing continuation rather than just a closure).


re: message polymorphism.
strings are often used for this kind of thing in limbo, as they're
easy to use, by-value (yet locally mutable) and it's trivial to
transfer them externally.

generally, Limbo programs tend to avoid polymorphism (although the
latest version does have parametric polymorphism) in favour of a
simple, direct style of coding.

channels i mentioned earlier in this respect.  dynamically loaded
modules mean that you can have several dynamically loaded pieces of
code each complying to the same interface.

i've used this to pleasing effect in some limbo programs.  for
example, a piece of "grid" software i did recently allows one to farm
out pieces of work to multiple clients and reliably collect them.  the
module that actually splits up the work and marshals the results is
separately implemented.  its interface is entirely specified by the
following self-contained module definition:

Taskgenerator: module {
	init:		fn(jobid: string, state: string, args: list of string): string;
	taskcount:	fn(): int;
	state:	fn(): string;
	start:		fn(id: string,
		tries:	int,
		spec: ref Clientspec,
		read: chan of (int, chan of array of byte, chan of int),
		write: chan of (array of byte, chan of string, chan of int),
		finish: chan of (int, big, chan of string)): (int, string);
	reconnect:	fn(id: string,
		read: chan of (int, chan of array of byte, chan of int),
		write: chan of (array of byte, chan of string, chan of int),
		finish: chan of (int, big, chan of string)): int;

	complete:	fn();
	quit:	fn();

	Clientspec: adt {
		addr: string;
		attrs: list of (string, string);
		nodeattrs: list of (string, string);
	};
	Started, Error, Nomore: con iota;
};

this uses the above mentioned forms of polymorphism in several ways:

multiple different implementations of Taskgenerator modules coexist
concurrently, each with its own unrelated state.

calling start() asks the task generator to start a new task; it
returns some channels that can then be used by the core software to
communicate with an instance of that task (usually a thread will be
started).  the interface is straightforward, and both sides of the
software can be written in a straightforward manner.

strings are used to hold arbitrary data (attribute-value pairs,
arbitrary client-created identifiers).

implementation is almost completely divorced from interface, making
the whole thing highly modular.  i can replace task generator modules
at run time with no hassle (and often do).

of course, it's no magic bullet, but the features of Limbo do seem to
me to work in synergy to produce a language that spurs creativity
rather than inviting perplexity.

  cheers,
    rog.

Re: [9fans] Re: advantages of limbo

[rog]

> Class Thread is not a part of the language. 'synchronized'
> is. What's wrong with Java synchronization? Can you please
> bring an example in Java and limbo where Java's synchronization
> is bad while limbo's approach is right?

a selection from Allen Holub's "Taming Java Threads":

: The "synchronised" keyword has several flaws:
: 
: 	1. You cannot specify a timeout value.
: 	2. You cannot interrupt a thread that is waiting to acquire a lock.
: 	3. You cannot safely acquire multiple locks.
: [...]
: 
: The wait()/notify() system also has problems:
: 	1. There is no way to detect whether wait() has returned normally
: 	or because of a timeout.
: 	2. There is no way to implement a traditional condition variable
: 	that remains in a "signalled" state.
: 	3. Nested-monitor lockout can happen too easily.
: 
: [...]
: 
: More facilities should be added to the language to support inter-thread
: communication. Right now, the PipedInputStream and PipedOutputStream
: classes can be used for this purpose, but they are much too inefficient for
: most applications.
: 
: [...]
: 
: Access to partially constructed objects should be illegal.
: The JLS currently permits access to a partially constructed object.
: For example, a thread created within a constructor can access the object
: being constructed, even though that object might not be fully
: constructed.
: 
: [...]
: 
: The lack of good access control makes threading more
: difficult than necessary. Often, methods don't have to
: be thread safe if you can guarantee that they be called
: only from synchronised subsystems.
: 
: [...]
: 
: The notion of immutability [...] is invaluable in multithreaded
: situations since read-only access to immutable objects doesn't
: have to be synchronised. Java's implementation of immutability
: isn't tight enough for two reasons:
: 
: 	1. It is possible for an immutable object to be accessed before it's
: 	fully created and this access might yield an incorrect value
: 	for some field.
: 	2. The definition of immutable [...] is too loose: Objects addressed by
: 	final references can indeed change state, even though the reference
: 	itself cannot change state.
: 
: [...]
: 
: There is also the problem that both class-level (static) and instance (non-static)
: methods can directly access class-level (static) fields. This access is
: dangerous because synchronising the instance method doesn't
: grab the class-level lock, so a synchronised static method can
: access the class field at the same time as a synchronised instance
: method.
: 
: [...]
: 
: The singleton-destruction problem discussed in Chapter 7 is a serious one.
: [in chapter 7:]
: There is a serious impediment to the correct implementation of Singleton:
: How do you get rid of the thing? The Singleton object is created on
: first use, but what if global resources like temporary files or database
: connections are created by the Singleton's constructor? How do you
: get rid of the temporary file or close the database connection in an
: orderly way? [...] Though I hate to end this section on a pessimistic note,
: I don't have an ideal solution to this problem. If you do, please write to me.
: 
: [...]
: 
: Daemon threads are shut down abruptly when all the non-daemon
: threads terminate. This is a problen when the daemon has created
: some sort of global resource (such as a database connection or a temporary
: file), but hasn't closed or destroyed that resource when it is terminated.
: 
: [...]
: 
: The suspend() and resume() methods should just be put back into
: Java. They're useful, and I don't like being treated like a kindergartener:
: Removing them simply because they are potentially dangerous - a thread
: can be holding a lock when suspended - is insulting. Let me decide
: whether or not I want to use them.
: 
: [...]
: 
: You should be able to interrupt any blocking operation, not just
: wait() and sleep(). [...] Right now, the only way to interrupt a blocking
: I/O operation on a socket is to close the socket, and there's no
: way to interrupt a blocking I/O operation on a file.

with all of these issues, Limbo either ducks the issue (by not
pretending to solve a problem it can't solve properly) or does things
right.

Re: [9fans] Re: advantages of limbo

[Bruce Ellis]

I feel like boyd, throwing off more than one message in a hit.

>> It does not use kludges like 'cyclic' to compensate for deficiencies
>>of the underlying virtual machine.

Absolutley wrong.  Cyclic is only in the language for diagnostic
purposes.  It has no effect on the code generated.  The VM
is not faulty.  Read some code.

regards

brucee

Re: [9fans] Re: advantages of limbo

[Bruce Ellis]

You had a bad experience.  The Inferno GC, well after philw
let me fix the bugs, is fantastic.  And it's difficult to explain to
a client that the reason their machine freezes is because they
are running java in a window and it's having a jolly good time
at marking and sweeping, thrashing like hell 'cause it's so
bloated and ... have a beer and it will be all right in a few minutes.

> Besides, are there measured comparisons of Java and Limbo in the
> area of memory usage and GC performance? My experience with implementing
> GC in virtual machines is that reference-counting+graph coloring can
> easily result in slower execution than mark'n'sweep.
> 
> David Tolpin

Re: [9fans] Re: advantages of limbo

[matt]

> byte them

you've been in CS too long Mr Nemo

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

> The Inferno environment itself may not be perfect, but access to the
> sources allows one to configure it to one's tastes.  The same is never
> going to apply to the Java VM because it always depends on the
> underlying platform.

Exactly, Java is not portable, as my students (and other profs.) find
out here now and then; the differences in the libraries always byte them
in the end; not to talk about how to do (or how to use) non-portable
services and supply them in a portable way.

Re: [9fans] Re: advantages of limbo

[lucio]

>> > Right now, Java and limbo  are in the same position of external
>> > tools artificially brought in. 
>> > 
>> I'm not the only one to believe that this is intentional, touted as an
>> advantage in both instances.  Or do you use the GNU Java compiler for
>> your development (don't shoot me, I know precious little about it)?
> 
> No, I don't think it is an advantage, as it is a feature of
> many other languages as well.  GNU Java compiler does not make
> any difference. I don't mean compiling limbo into object code.
> I mean  making *VM a part of the system. I want it to
> be loaded once and retain state. I want it to be a service,
> not an application.
> 
Abstracting the language from the operating system is critical to
portability.  And portability has yet to be knocked (the way
object-oriented paradigm and multithreading have been) as a bad thing.

As for running the VM as a service, you have to choose between the
namespace being something the VM inherits or something the VM
manipulates.  Where the namespace is the most critical resources in
the Plan 9 environment and is largely what sets Inferno apart from the
neutral environment the Java VM supplies (and, in my opinion,
unsuccessfully attempts to enhance with crippling security
"features").

It seems to me that on this forum the consensus is that the ability to
manipulate the namespace is something special Plan 9 and Inferno do
and none of us would consider sacrificing it without just cause.

The Inferno environment itself may not be perfect, but access to the
sources allows one to configure it to one's tastes.  The same is never
going to apply to the Java VM because it always depends on the
underlying platform.  Now, perhaps I ought to ask you to explain why
you'd prefer the Inferno VM to be different from its present form and
how you'd prefer it to be or, to be nasty, what's stopping you from
shaping it to your requirements.

++L

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

> Class Thread is not a part of the language. 'synchronized'
> is. What's wrong with Java synchronization? Can you please
> bring an example in Java and limbo where Java's synchronization
> is bad while limbo's approach is right?

It is, if it's the only means I have to write concurrent programs in java.

Regarding sync, you can pretty easily get deadlocks. They
did admit that they did concurrency wrong IIRC, you don't have monitors
nor any other clean mechanism.

> How exactly are closures  expressed with module pointers?
> Can a module be created dynamically?

It can be loaded dynamically. I think that suffices.

Re: [9fans] Re: advantages of limbo

[Charles Forsyth]

>>Or is it what the paper on limbo calls 'graph coloring'?

the basis of the garbage collector is described in
a paper by huelsbergen and winterbottom that
you should be able to find via google/citeseer
given those names and "real-time garbage".
the actual implementation differs in various ways
but that gives some of the background.

Re: [9fans] Re: advantages of limbo

[Rob Pike]

> Is there any other reason reference loops are not very common amongs
> limbo programmers besides limitations of the garbage collector?

what limitations?

seriously,  you should read again what presotto wrote.  using reference
counting coupled with a cyclic collector means that most of the time you
have complete control over the timing of your loops.  also, the memory
footprint of your program can be exactly what it needs; no requirement
to have a large arena to make the collection efficient.  these issues 
are
critical for the sort of embedded applications limbo was created for.
it just happened that they're also useful for general programming.


the real story though is this: for the last few days, every time a 
criticism
is raised about some piece of software, the arguments are always of
the form "but zzz can do it" for some value of zzz, yet what's really
being compared is some modern or idealized version of zzz vs. an
earlier, functional piece of plan 9 or inferno code.  yes, java *can*
do good GC.  yes, linux threads *can* create local storage.
and so on and so on.  but the point is:

	they could *not* do them when the programs (inferno, limbo,
	plan 9 threads, etc. etc.) you are criticizing were written.

we're writing about historical systems here and people are carping
that they are no better than what you can get today.  well, perhaps,
but so what?

oh, to hell with it, i'll rephrase.  linux is perfect. java is perfect.
there is no better way to think than to accept what hordes of
students believe is the one true way. no correct thought was
every achieved by anyone over 18.  i will never again write a
thought that could possibly deviate from the official plans to
be recorded in some upcoming software release from some
open source organization.

sorry for wasting your time.

-rob

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> > It is a wrong assumption that mark'n'sweep requires staged garbage
> > collection. Why don't you just use propagating markers? It is marginally
> > complex algorithmically, instantly throws away rubbish and does not
> > make a difference between cyclic and acyclic data structures.
>
> I don't know about this.  Could you provide a reference?
>

I'll try to find; I used to implement it according to a paper
from a conference but I don't have the exact link. The idea
is that you maintain and update marks (as in mark'n'sweep)
instantly. Adding or deleting a reference induces modifications
in a subgraph of the marked graph. Nodes which were marked and
become unmarked  can be deleted and it is almost equivalent in
response time to reference counting.  Graph updates must be
synchronized on reference modifications, and nowhere else.

Or is it what the paper on limbo calls 'graph coloring'?

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> > Right now, Java and limbo  are in the same position of external
> > tools artificially brought in. 
> > 
> I'm not the only one to believe that this is intentional, touted as an
> advantage in both instances.  Or do you use the GNU Java compiler for
> your development (don't shoot me, I know precious little about it)?

No, I don't think it is an advantage, as it is a feature of
many other languages as well.  GNU Java compiler does not make
any difference. I don't mean compiling limbo into object code.
I mean  making *VM a part of the system. I want it to
be loaded once and retain state. I want it to be a service,
not an application.

> <http://www.vorlesungen.uni-osnabrueck.de/informatik/inferno/web/infernojava.html>
> if you're still curious.

Yes, thank you, I am reading it.

Re: [9fans] Re: advantages of limbo

[David Presotto]

> It is a wrong assumption that mark'n'sweep requires staged garbage
> collection. Why don't you just use propagating markers? It is marginally
> complex algorithmically, instantly throws away rubbish and does not
> make a difference between cyclic and acyclic data structures.

I don't know about this.  Could you provide a reference?

Re: [9fans] Re: advantages of limbo

[David Presotto]

> Does that mean that designers of Inferno windowing system were
> required to avoid using cyclic references in window structures?
> That is, a window does not know who its creator is? 

Yup, as long as something had a reference to the window, the window stayed
around.  If the reference is in  cyclic struct that becomes unreachable,
it will get collected.  However the immediacy that users expect is lost.

> It's a decision. But a limiting one. Influenced by an implementation.
> Just running garbage collector with limited scope would do it
> without limitations.

All decisions are limiting.  You pay extra for limited
scope just as you do for reference counting.  If you limit the scope
small enough that you release things as quickly, then you have
the equivalent of reference counting with higher cost.

>  It was not a tradeoff of normal garbage collection. Fixed-time garbage
> collection techniques existed long before java. It was just an early
> implementation to make it running.

We lived with this 'just to make it running' for several years.  The jdk's
now contain multiple gc techniques including fixed time ones.  From outside
the VM the two are indistinguishable unless you care when the memory is
freed, i.e., if when the freeing is visible.  That happens both in  java
and in limbo if the finalize routines can have extrernally visible effects.

> Is there any other reason reference loops are not very common amongs
> limbo programmers besides limitations of the garbage collector?

The garbage collector has little influence on our programming of cyclic
structs, expecially since the gc correctly collects those cycles when they
are freed.  However, people seem to understand dags better then cyclic
structures and make less mistakes manipulating them, so they use them more often.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> any Java i've ever seen is that most storage is reclaimed by

Are there any comparable programs that can show that limbo
takes much less memory than Java?

> the reference counter, because many common structures
> are not, in fact, cyclic.  DAGs by definition are not cyclic.
> when programming (even on large machines)
> it is good discipline (as Wirth observed) not to create the
> garbage in the first place.  that also means that the incremental
> garbage collector can be less obtrusive.

In Wirth's source codes of Oberon System there are many cyclic
structures relying on mark'n'sweep garbage collector implemented
in the system. And windows are closed timely.

> >>is there any other reason reference loops are not very common amongs
> >>limbo programmers besides limitations of the garbage collector?
>
> oh for heaven's sake.  i must not be explaining this very well.
> there is no [inherent] `limitation of the garbage collector'.
> it garbage collects arbitrary rubbish just fine.  

How are resources (time, space and delay) compared for cyclic and
acyclic structures? For example, a cyclic and acyclic list with
the same data?

> the reference counted
> side does, however, reclaim storage the very instant the data becomes rubbish,
> which must certainly yield a smaller working set than any garbage collector
> scheme that has one always trundling along later.

It is a wrong assumption that mark'n'sweep requires staged garbage
collection. Why don't you just use propagating markers? It is marginally
complex algorithmically, instantly throws away rubbish and does not
make a difference between cyclic and acyclic data structures.

David

Re: [9fans] Re: advantages of limbo

[Charles Forsyth]

one of the reasons that Limbo runs in much smaller spaces than
any Java i've ever seen is that most storage is reclaimed by
the reference counter, because many common structures
are not, in fact, cyclic.  DAGs by definition are not cyclic.
when programming (even on large machines)
it is good discipline (as Wirth observed) not to create the
garbage in the first place.  that also means that the incremental
garbage collector can be less obtrusive.

>>is there any other reason reference loops are not very common amongs
>>limbo programmers besides limitations of the garbage collector?

oh for heaven's sake.  i must not be explaining this very well.
there is no [inherent] `limitation of the garbage collector'.
it garbage collects arbitrary rubbish just fine.  the reference counted
side does, however, reclaim storage the very instant the data becomes rubbish,
which must certainly yield a smaller working set than any garbage collector
scheme that has one always trundling along later.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> > Are there code examples in limbo and Java which can convince someone
> > that limbo is more convenient?
> > 
> ...  you're edging closer to a religious topic.  There are
> philosophical differences between Limbo and Java that can only be
> considered, not explained.  Like there are between Pascal and C. Can
> you convincingly state that C is _better_ than Pascal without
> resorting to some untestable philosophical principle?  I know I
> cannot, in either direction.

C and Pascal where created for different programming applications.
Pascal had never been thought of as  a language for systems programming.

I'd consider philosophically comparing C and Oberon, but it's another
issue.

Going back to limbo, I see one advantage that would overweigh all
the drawbacks. If limbo could be integrated into an OS other than
Inferno (e.g. Plan 9) better than perl is (that is, if one can and
does rewrite acme in limbo for Plan 9, for example), then it is a
difference big enough to win.

Right now, Java and limbo  are in the same position of external
tools artificially brought in. 


> Where I think Limbo has the edge, is that it is not the product of a
> marketing organisation that has discovered yet another marketable
> product, but that it grew from a desire to get things done to a clear
> philosophical direction.

What is the philosophical direction?

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> From 9fans-admin@cse.psu.edu  Tue Mar  2 12:02:21 2004
> Subject: Re: [9fans] Re: advantages of limbo
> From: David Presotto <presotto@closedmind.org>
> To: 9fans@cse.psu.edu
> Content-Type: text/plain; charset="US-ASCII"
> Date: Tue, 2 Mar 2004 03:02:46 -0500
>
> On the topic of garbage collectors, one of the main reasons for reference
> counting objects and immediately releasing them when they become unreachable
> was to use garbage collection to allow control not only of memory but also
> resources memory represents.  The typical example given is one of windows
> that go away as soon as the last reference to them (actually the object representing
> them) goes away.  

Does that mean that designers of Inferno windowing system were
required to avoid using cyclic references in window structures?
That is, a window does not know who its creator is? 

It's a decision. But a limiting one. Influenced by an implementation.
Just running garbage collector with limited scope would do it
without limitations.

> Also, the reference counting had a distinct advantage of
> being fixed time.  We had a terrible time with java systems of the time
> going away for long periods, both because of the garbage collector going
> off and because of the odd interactions in finalize routines in various
> classes.

It was not a tradeoff of normal garbage collection. Fixed-time garbage
collection techniques existed long before java. It was just an early
implementation to make it running.

> Over the years since limbo appeared, java garbage collection has changed
> radicly and often, drasticly reducing the 'time to take a coffee break'
> garbage collection runs.  By the 1.4.1 jdk, java included 6 or more
> gabage collection strategies and all sorts of tuning parameters.  Along
> the way all sorts of user code was written to avoid tickling the collectors
> at the wrong time or to get things done before they went off.   That's
> a hell of a lot of effort to avoid the small differences advertised by
> the proponents of m&s and generational gc over reference counting.

Among 61864 lines of tight Java code I have been involved in writing
during last two years there is not a single line which was written to
avoid tickling the collector at the wrong time. It just works.

> Of course, limbo isn't immune from odd timings.  However, they do require
> reference loops and those seem not very common amongst limbo programmers.
>

Is there any other reason reference loops are not very common amongs
limbo programmers besides limitations of the garbage collector?

David

Re: [9fans] Re: advantages of limbo

[Charles Forsyth]

>>Unfortunately. limbo the language contains a fix for the  reference-counting
>>garbage collector. It uses keyword cyclic because garbage collector
>>needs it. 

no, absolutely not.  it has no effect at run-time and does not appear in the
dis files or anywhere else at run-time.   all it does is suppress a diagnostic
at compile-time, so that a programmer who is anxious to avoid creating
cyclic data (if only by accident) can have that checked at compile time, and
it provides a similar cue for a reader.  on the other hand, the presence
of cyclic does not mean it will necessarily be cyclic, just that the compiler
cannot determine it will not.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> >>garbage collector. It uses keyword cyclic because garbage collector
> >>needs it. 
>
> no, absolutely not.  it has no effect at run-time and does not appear in the
> dis files or anywhere else at run-time.   all it does is suppress a diagnostic
> at compile-time, so that a programmer who is anxious to avoid creating
> cyclic data (if only by accident) can have that checked at compile time, and
> it provides a similar cue for a reader.  on the other hand, the presence
> of cyclic does not mean it will necessarily be cyclic, just that the compiler
> cannot determine it will not.

Is there any other reason for a programmer to be anxious to avoid
creating cyclic data than reference-counting garbage collection?

Re: [9fans] Re: advantages of limbo

[David Presotto]

On the topic of garbage collectors, one of the main reasons for reference
counting objects and immediately releasing them when they become unreachable
was to use garbage collection to allow control not only of memory but also
resources memory represents.  The typical example given is one of windows
that go away as soon as the last reference to them (actually the object representing
them) goes away.  Also, the reference counting had a distinct advantage of
being fixed time.  We had a terrible time with java systems of the time
going away for long periods, both because of the garbage collector going
off and because of the odd interactions in finalize routines in various
classes.

Over the years since limbo appeared, java garbage collection has changed
radicly and often, drasticly reducing the 'time to take a coffee break'
garbage collection runs.  By the 1.4.1 jdk, java included 6 or more
gabage collection strategies and all sorts of tuning parameters.  Along
the way all sorts of user code was written to avoid tickling the collectors
at the wrong time or to get things done before they went off.   That's
a hell of a lot of effort to avoid the small differences advertised by
the proponents of m&s and generational gc over reference counting.

Of course, limbo isn't immune from odd timings.  However, they do require
reference loops and those seem not very common amongst limbo programmers.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> > The only claim I have found is that reference counting + coloring
> > is better than mark'n'sweep. Given that Java's GC is not mark'n'sweep
> > for a long time already, and the performance problems related to
> > memory management are insignificant since the release of HotSpot,
> > are there any other advantages of limbo over Java?
> > 
> No, at that level of detail I'm really neither competent nor really
> likely to be persuaded that computer languages can be meaningfully
> compared.  When you start going that deep into the architecture, you
> may as well resort to assembler.  At least, I would, largely because I
> enjoy assmebler programming unless the host architecture is positively
> foul.

Unfortunately. limbo the language contains a fix for the  reference-counting
garbage collector. It uses keyword cyclic because garbage collector
needs it. 

> > Besides, are there measured comparisons of Java and Limbo in the
> > area of memory usage and GC performance? My experience with implementing
> > GC in virtual machines is that reference-counting+graph coloring can
> > easily result in slower execution than mark'n'sweep.
> > 
> Again, too detailed to be interesting, in my opinion.  Programming
> languages are notations to express algorithms: the efficiency must lie
> in the algorithms, not the translators (also, in my opinion).

But the efficiency issue of GC technique was the only advantage 
of limbo over Java mentioned in the article. If it cannot be
used, then what are other advantages?

Are there code examples in limbo and Java which can convince someone
that limbo is more convenient?

David

Re: [9fans] Re: advantages of limbo

[lucio]

>> The Inferno/Java paper (somewhere on the web site, but likely also in
>> the Plan 9 distribution) covers it rather nicely.
> 
> Google brings inexistent link.
> 
Hm, maybe forsyth can help you with a copy, I'd have to search for one
myself.  If you want to wait, I must have one on the old Inferno CD.

> The only claim I have found is that reference counting + coloring
> is better than mark'n'sweep. Given that Java's GC is not mark'n'sweep
> for a long time already, and the performance problems related to
> memory management are insignificant since the release of HotSpot,
> are there any other advantages of limbo over Java?
> 
No, at that level of detail I'm really neither competent nor really
likely to be persuaded that computer languages can be meaningfully
compared.  When you start going that deep into the architecture, you
may as well resort to assembler.  At least, I would, largely because I
enjoy assmebler programming unless the host architecture is positively
foul.

> Besides, are there measured comparisons of Java and Limbo in the
> area of memory usage and GC performance? My experience with implementing
> GC in virtual machines is that reference-counting+graph coloring can
> easily result in slower execution than mark'n'sweep.
> 
Again, too detailed to be interesting, in my opinion.  Programming
languages are notations to express algorithms: the efficiency must lie
in the algorithms, not the translators (also, in my opinion).

++L

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> Are you including all the plethora (eg. Thread) in the
> discussion? Have you considered how threads merge with
> synchronized?

Class Thread is not a part of the language. 'synchronized'
is. What's wrong with Java synchronization? Can you please
bring an example in Java and limbo where Java's synchronization
is bad while limbo's approach is right?

> BTW, for closures and polymorphism you'd use module pointers
> in Limbo; I forgot to reply to this earlier.

How exactly are closures  expressed with module pointers?
Can a module be created dynamically?

David Tolpin

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]

Are you including all the plethora (eg. Thread) in the
discussion? Have you considered how threads merge with
synchronized? I don't agree that it's simpler. Thus, probably
we won't agree in the result of comparing both of them.
But it's nice to have several languages so that we could choose.

BTW, for closures and polymorphism you'd use module pointers
in Limbo; I forgot to reply to this earlier.

[-- Attachment #2: Type: message/rfc822, Size: 2711 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: advantages of limbo
Date: Tue, 2 Mar 2004 11:30:01 +0400 (AMT)
Message-ID: <200403020730.i227U1tg071218@adat.davidashen.net>

> But just to tell you what I mean, I feel that limbo lacks those
> features that make Java a complex laguage, yet it retains
> those that make it easy to reuse code. That's arguable, of course.

But Java is a SIMPLER language than limbo. 

It has fewer basic structures and orthogonal notions in the language.

It does not use ugly idea of separating module interfaces from
module implementations.

It does not use kludges like 'cyclic' to compensate for deficiencies
of the underlying virtual machine.

Yet it is more powerful in expressing algorithms. Things like closures
or message polymorphism are natural and easy to express in Java, while
either not possible or inconvenient in limbo.

David

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> But just to tell you what I mean, I feel that limbo lacks those
> features that make Java a complex laguage, yet it retains
> those that make it easy to reuse code. That's arguable, of course.

But Java is a SIMPLER language than limbo. 

It has fewer basic structures and orthogonal notions in the language.

It does not use ugly idea of separating module interfaces from
module implementations.

It does not use kludges like 'cyclic' to compensate for deficiencies
of the underlying virtual machine.

Yet it is more powerful in expressing algorithms. Things like closures
or message polymorphism are natural and easy to express in Java, while
either not possible or inconvenient in limbo.

David

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

You did for a real  program? Or for a simple example?
I started to feel the difference only after doing my first
real limbo program.

But just to tell you what I mean, I feel that limbo lacks those
features that make Java a complex laguage, yet it retains
those that make it easy to reuse code. That's arguable, of course.

[-- Attachment #2: Type: message/rfc822, Size: 2198 bytes --]

From: David Tolpin <dvd@davidashen.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Re: advantages of limbo
Date: Tue, 2 Mar 2004 11:08:07 +0400 (AMT)
Message-ID: <200403020708.i22787H3071038@adat.davidashen.net>

> > are there any other advantages of limbo over Java?
>
> Sure, the language.
> Just try to write a program in both and compare.

I did. Am I missing something? How closures
are expressed in limbo?

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> > are there any other advantages of limbo over Java?
>
> Sure, the language.
> Just try to write a program in both and compare.

I did. Am I missing something? How closures
are expressed in limbo?

Re: [9fans] Re: advantages of limbo

[Fco.J.Ballesteros]

> are there any other advantages of limbo over Java?

Sure, the language.
Just try to write a program in both and compare.

Re: [9fans] Re: advantages of limbo

[David Tolpin]

> The Inferno/Java paper (somewhere on the web site, but likely also in
> the Plan 9 distribution) covers it rather nicely.

Google brings inexistent link.

Object not found
The object /inferno/infernojava.html does not exist on this server.

I've found an article on similar subject, namely

http://www.cs.bell-labs.com/cm/cs/who/rob/hotchips.html

The only claim I have found is that reference counting + coloring
is better than mark'n'sweep. Given that Java's GC is not mark'n'sweep
for a long time already, and the performance problems related to
memory management are insignificant since the release of HotSpot,
are there any other advantages of limbo over Java?

Besides, are there measured comparisons of Java and Limbo in the
area of memory usage and GC performance? My experience with implementing
GC in virtual machines is that reference-counting+graph coloring can
easily result in slower execution than mark'n'sweep.

David Tolpin