Newsgroups: comp.lang.java,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!scramble.lm.com!news.math.psu.edu!news.cse.psu.edu!uwm.edu!cs.utexas.edu!howland.reston.ans.net!newsfeed.internetmci.com!nntp-hub2.barrnet.net!venus.sun.com!wnoc-sfc-news!kogwy!math-keio!mad
From: mad@math.keio.ac.jp (MAEDA Atusi)
Subject: Re: Heaps, distributed computing, and continuations (Was: Re: Will Java kill C++?)
In-Reply-To: cch@an-teallach.com's message of 29 Apr 1996 11:35:52 GMT
Message-ID: <MAD.96May6025044@tanzanite.math.keio.ac.jp>
Sender: news@math.keio.ac.jp
Nntp-Posting-Host: tanzanite
Reply-To: mad@math.keio.ac.jp
Organization: Faculty of Sci. and Tech., Keio Univ., Yokohama, Japan.
References: <3134D499.653E@ix.netcom.com> <313613B2.136E@ksopk.sprint.com>
	<4i7qhl$ik6@cronkite.seas.gwu.edu> <4iuhi7$fmf@sundog.tiac.net>
	<4iumap$mn5@hustle.rahul.net> <31582A45.3742@vmark.com>
	<3163C031.4FB1@esec.ch> <3164888D.2B01@concentric.net>
	<4kbfn8$1bu@news1.is.net> <4kqjf6$kh0@kaiwan009.kaiwan.com>
	<317173F1.5790@concentric.net> <4l194e$q11@galaxy.ucr.edu>
	<31743669.62A1@concentric.net> <4l3432$ebu@galaxy.ucr.edu>
	<317c18c9.1295272@news.mxol.com>
	<knight.830283487@tina.mrco.carleton.ca>
	<317E4F7A.1776@ccm.hf.intel.com>
	<CCH.96Apr29123552@suilven.an-teallach.com>
Date: Sun, 5 May 1996 17:50:44 GMT
Lines: 82
Xref: glinda.oz.cs.cmu.edu comp.lang.java:46983 comp.lang.smalltalk:38330

In article <CCH.96Apr29123552@suilven.an-teallach.com> cch@an-teallach.com (Conrad Chin) writes:

    > In article <317E4F7A.1776@ccm.hf.intel.com> Patrick Logan <patrick_d_logan@ccm.hf.intel.com> writes:
    >> From: Patrick Logan <patrick_d_logan@ccm.hf.intel.com>
    >> Newsgroups: comp.lang.java,comp.lang.smalltalk
    >> Date: Wed, 24 Apr 1996 08:57:46 -0700
    >> 
    >> A lot has been written about the implementation of Standard ML of
    >> New Jersey which allocates all "contexts" in the heap at very little
    >> cost relative to the stack. I believe (its been a while) the reason
    >> for the good performance is due to the performance of the garbage
    >> collector in handling the youngest generation of objects including
    >> the out-of-date "contexts".

    >> ...

    > It's a while since I looked at this stuff so things may have
    > progressed.  But, as I remember, the argument is that heap allocation
    > is faster than stack allocation if you have enough memory to allow you
    > to perform copying garbage collections "infrequently".  This is

Well, this argument of asymptotic behavior of GC (copying collector
performs better than mark and sweep collecter if there are enough
memory) is, according to GC researchers, turned out to be a myth.
Check out, e.g. ftp://parcftp.xerox.com/pub/gc/complexity.html

What Patric Logan is talking about is "generation based garbage
collection", which makes garbage collection drastically faster.

For information about generation based garbage collection and GC in
general, see Paul Wilson's great survey "Uniprocessor Garbage
Collection Techniques" (in Springer-Verlag LNCS 637), which is also
available on-line in ftp://cs.utexas.edu/pub/garbage/.  Also, GC-faq
(http://www.centerline.com/people/chase/GC/GC-faq.html) contains many
useful informations (although immature yet).

    > I
    > believe there's a paper by Andrew Appel on this - I can dig out the
    > reference if anyones interested.

I guess this is the article you mentioned:

@article{Appel:GCCBFTSA,
    author = "Appel, Andrew W.",
    title = "Garbage Collection Can Be Faster Than Stack Allocation",
    journal = Information Processing Letters,
    volume = 25,
    number = 4,
    month = jun,
    year = 1987, 
    pages = "275--279"
}

I'd like to furthre recommend:

@inproceedings( Hanson90Efficient, 
  author =	{Chris Hanson}, 
  title =	{Efficient Stack Allocation for Tail-Recursive Languages}, 
  year =	1990, 
  month =	jun, 
  booktitle =	{Proceedings of the 1990 ACM Conference on Lisp
and Functional Programming}, 
)

In this paper, author insists that implementation of Scheme should not 
pop stack frames but instead it shoud garbage collect them (by special 
garbage collector that only handles stack frames).

    > On the other hand, stack allocation has a fixed overhead of a few m/c
    > instructions to perform allocation and deallocation.

It's true in languages that doesn't have first-class contiunations.
But you should also consider that heap allocation is just as cheap in
systems with copying collector as stack push, and you can't pop stack
frames so cheaply if the language has first-class continuations.  You
must either copy all stack frames at creation of contiuation or retain
stack frame until you make sure (by GC or by other means) no
continuations are referring to that frame.  So allocating frames in
stack might have little advantages over heap allocation in such a
language.

				MAEDA Atusi
