[UNSURE]Recent changes impeded building and testing on smaller boxes

[François Perrad]

2010/9/25 James E Keenan <jkeen at verizon.net>

> During development of the gc_massacre branch, I tried to build and test
> parrot on both Linux/i386 and Darwin/PPC.  I have used each of these
> machines for testing since I joined the Parrot project in late 2006. While I
> have never explicitly tracked how fast 'make' and 'make test' run on those
> boxes, I do have a general sense of how long those processes take.
>
> I noticed that when I was building and testing the gc_massacre branch on
> the Darwin/PPC box (a 6-year-old iBook G4 running Mac OS X 4.11), all other
> operations on that machine would slow to a crawl.  For example, using
> Alt-Tab to toggle among programs would work only with 30-60 seconds of
> latency.  Switching from terminal to a browser (SeaMonkey or Camino)
> sometimes took 5 minutes.  This slowdown was most noticeable in the parts of
> 'make' where './ops2c' was being run.  'make test' ground to a halt in
> 't/compilers/opsc/*.t'.
>
> Trunk was continuing to build and test satisfactorily at this time, but
> once the gc_massacre branch was merged into trunk at r49269, trunk began to
> suffer all the same problems that the branch had.  My unscientific
> impression is that 'make' now takes 10% longer to complete (e.g., 12 minutes
> version 10-1/2 minutes), though it has taken as long as 19 minutes.  But
> what is most striking is that 'make test' won't complete at all unless I
> manually delete the tests in 't/compilers/opsc/*.t' from the roster of
> tests.  The '01' test in that directory will complete ... and then I will
> get no output whatsoever from the '02' test.  If I Ctrl-C to kill the '02'
> test, the '03' test will run -- but other tests in this directory will hang
> indefinitely as well.
>
> Last night bacek was able to devote some attention to this problem.  He
> pointed to a particular line of code recently merged in from the gc_massacre
> branch and asked me to make a manual change:
>
> $ svn diff
> Index: src/gc/gc_ms2.c
> ===================================================================
> --- src/gc/gc_ms2.c     (revision 49323)
> +++ src/gc/gc_ms2.c     (working copy)
> @@ -623,7 +623,8 @@
>
>         /* Collect every 256M allocated. */
>         /* Hardcode for now. Will be configured via CLI */
> -        self->gc_threshold = 256 * 1024 * 1024;
> +/*        self->gc_threshold = 256 * 1024 * 1024; */
> +        self->gc_threshold = 64 * 1024 * 1024;
>     }
>     interp->gc_sys->gc_private = self;
>
>
> 256M happens to be amount of Physical Memory reported by 'top' for this
> machine.  Changing the gc_threshold from 256M to 64M did enable 'make test'
> to run completely (including t/compilers/opsc/*.t) and PASS in about 19
> minutes.  So the value of the gc_threshold does have a significant impact on
> whether parrot will run (in any meaningful sense) on a particular machine.
>
> Now, I know that there are some who will snigger at the thought of trying
> to test Parrot on a machine that is more than 6 years old.  "Just go out and
> buy a new laptop, kid51.  It'll be sure to have at least 10 times as much
> memory as that ancient, battered box."
>
> Needless to say, I don't accept that logic -- and not only because
> "ancient, battered box" describes the box's owner as well as the box. As I
> pointed out when voicing a similar problem with Rakudo Star, if we've been
> able to build and run a particular program (Parrot, Rakudo Perl, whatever)
> on a particular machine for years on end, and if we can no longer do so,
> then our scientific rigor ought to require us to determine *why* we can no
> longer do so, rather than sweeping the problem under the rug.  AFAICT, we
> have never specified minimum memory or other requirements for building or
> running Parrot on any particular box. Hence, it seems to me to be reasonable
> to assume that if Parrot build on a particular box in 2006, it will continue
> to do so indefinitely unless building on that box is explicitly deprecated
> by the project.  After all, it's quite possible that when Parrot runs on
> embedded devices in the future, it will have to run in an environment with
> even less memory than this ancient, battered box has.
>

I've the same problem, because I split my physical memory with many VMware
appliances.
For example, an appliance with Xubuntu 10.04 and only 256 M of RAM allows to
build and test Parrot without problem
if gc_threshold = 64M. But when gc_threshold = 256M, the system obviously
collapses.

François


> Thank you very much.
> kid51
>
> _______________________________________________
> http://lists.parrot.org/mailman/listinfo/parrot-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20100926/6f797dd3/attachment.html>