Discussion:
[Gc] A student assignment based on bdwgc
(too old to reply)
Henryk Michalewski
2015-03-18 00:02:02 UTC
Permalink
Raw Message
I am running a CS 101 class at the CS department of the University of
Warsaw. This class is focused on the C language. I like the idea of
making a student software project based on bdwgc and contemplated
options such as
- implementation of alternative gc algorithm
- some optimizations/improvements in the current code
- building an additional tool conceptually related to bdwgc
The final project should not exceed 2000-3000 lines.

Maybe this is a stupid idea in the sense that in your view this is a
too tough assignment - please feel free to inform me about it.
Otherwise, I would be glad to hear some specific recommendations from
the authors!

Yours, Henryk Michalewski
--
http://www.mimuw.edu.pl/~henrykm
Bruce Hoult
2015-03-19 02:52:37 UTC
Permalink
Raw Message
I think it's an excellent idea to introduce students to C programming using
a garbage collector. Many professional programmers don't seem to realize
that GC is not a convenience reserved to programmers using Java or Python.
Using C with GC is much more pleasant (and safe!) than using C with
malloc/free.

I don't think it's realistic to have CS101 students modify bdwgc. Graduate
students or advanced undergrads maybe, but it would be an extraordinary
first year student who could be successful.

However simply reading some of the code may be instructive. Bdwgc is a
software library that has existed in some form for nearly THIRTY years!
See:

Boehm, H., and M. Weiser, "Garbage Collection in an Uncooperative
Environment", Software Practice & Experience, September 1988, pp. 807-820.

http://www.hboehm.info/spe_gc_paper/preprint.pdf

Boehm, Hans-J., Alan J. Demers, and James E. Donahue, ‘‘A Programmer’s
Introduction to Russell’’, Technical Report 85-16, Computer Science, Rice
University, 1985

http://www.math.bas.bg/bantchev/place/russell/russell-intro.pdf

Most of the description in the first paper still applies. There are some
changes, for example the block header information has since been taken out
of the blocks, and fewer distinct object sizes are supported (object
requests are rounded up to the next larger size). However the basic
principles still apply.

Over the last 25 or so years bdwgc has been ported to a vast number of
different operating systems. It may be instructive for students to see how
differences between the different machines have been coped with in real
production code (largely by macros and conditional compilation).


I don't think there is much of a wish list for bdwgc. The gc code itelf
been pretty well optimised and debugged over the last 25 years.

There is room for additional facilities for debugging. For example dumping
various descriptions of the heap, or explaining why a particular object
can't be collected. That kind of thing. That might be within reach of a
good student.

One thing I'd personally like is to see it usable on smaller machines. In a
previous life I used it on mobile phones with as little as 400 KB of RAM,
and the fact that it had (from memory) about 150 KB of statically allocated
global arrays was pretty annoying. I got that down to I think about 15 KB,
but unfortunately I wasn't allowed to distribute that code, and don't have
access to it any more anyway.

I'd love to be able to use GC in programming microcontrollers such as the
Arduino. Unfortunately, you'll never fit bdwgc into something with 2 KB of
RAM. But creating a new GC suitable for such uses might be a good project.
Some of the ideas in the "Chicken" Scheme compiler might be useful.


On Wed, Mar 18, 2015 at 1:02 PM, Henryk Michalewski <
Post by Henryk Michalewski
I am running a CS 101 class at the CS department of the University of
Warsaw. This class is focused on the C language. I like the idea of
making a student software project based on bdwgc and contemplated
options such as
- implementation of alternative gc algorithm
- some optimizations/improvements in the current code
- building an additional tool conceptually related to bdwgc
The final project should not exceed 2000-3000 lines.
Maybe this is a stupid idea in the sense that in your view this is a
too tough assignment - please feel free to inform me about it.
Otherwise, I would be glad to hear some specific recommendations from
the authors!
Yours, Henryk Michalewski
--
http://www.mimuw.edu.pl/~henrykm
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Carsten Kehler Holst
2015-03-19 08:23:39 UTC
Permalink
Raw Message
We have wish, but I believe it is beyond a 101 course.

It has to do with bdwgc running concurrently.
We use bdwgc in our prolog runtime system.
Unfortunately it doesn’t give the speedups we had hoped for if we run algorithms concurrently.
The problem seems to be that typed allocations haven’t been optimised for concurrency. (typed allocations aren’t moved to thread local storage).
If we make an experiment where we use untyped allocations (nonatomic) then we get reasonably speedups, not brilliant but much better than if we use type allocations.

So improving concurrent behaviour (we are on a win32 platform) is on the wishlist.
But it is probably also beyond a CS101 course.
But then again figuring out what the problem is might be within the scope.

Best regards
Carsten Kehler Holst
Prolog Development Center


From: bdwgc-***@lists.opendylan.org [mailto:bdwgc-***@lists.opendylan.org] On Behalf Of Bruce Hoult
Sent: 19 March 2015 03:53
To: Henryk Michalewski
Cc: ***@lists.opendylan.org
Subject: Re: [Gc] A student assignment based on bdwgc

I think it's an excellent idea to introduce students to C programming using a garbage collector. Many professional programmers don't seem to realize that GC is not a convenience reserved to programmers using Java or Python. Using C with GC is much more pleasant (and safe!) than using C with malloc/free.

I don't think it's realistic to have CS101 students modify bdwgc. Graduate students or advanced undergrads maybe, but it would be an extraordinary first year student who could be successful.

However simply reading some of the code may be instructive. Bdwgc is a software library that has existed in some form for nearly THIRTY years! See:

Boehm, H., and M. Weiser, "Garbage Collection in an Uncooperative Environment", Software Practice & Experience, September 1988, pp. 807-820.

http://www.hboehm.info/spe_gc_paper/preprint.pdf

Boehm, Hans-J., Alan J. Demers, and James E. Donahue, ‘‘A Programmer’s Introduction to Russell’’, Technical Report 85-16, Computer Science, Rice University, 1985

http://www.math.bas.bg/bantchev/place/russell/russell-intro.pdf

Most of the description in the first paper still applies. There are some changes, for example the block header information has since been taken out of the blocks, and fewer distinct object sizes are supported (object requests are rounded up to the next larger size). However the basic principles still apply.

Over the last 25 or so years bdwgc has been ported to a vast number of different operating systems. It may be instructive for students to see how differences between the different machines have been coped with in real production code (largely by macros and conditional compilation).


I don't think there is much of a wish list for bdwgc. The gc code itelf been pretty well optimised and debugged over the last 25 years.

There is room for additional facilities for debugging. For example dumping various descriptions of the heap, or explaining why a particular object can't be collected. That kind of thing. That might be within reach of a good student.

One thing I'd personally like is to see it usable on smaller machines. In a previous life I used it on mobile phones with as little as 400 KB of RAM, and the fact that it had (from memory) about 150 KB of statically allocated global arrays was pretty annoying. I got that down to I think about 15 KB, but unfortunately I wasn't allowed to distribute that code, and don't have access to it any more anyway.

I'd love to be able to use GC in programming microcontrollers such as the Arduino. Unfortunately, you'll never fit bdwgc into something with 2 KB of RAM. But creating a new GC suitable for such uses might be a good project. Some of the ideas in the "Chicken" Scheme compiler might be useful.


On Wed, Mar 18, 2015 at 1:02 PM, Henryk Michalewski <***@gmail.com<mailto:***@gmail.com>> wrote:
I am running a CS 101 class at the CS department of the University of
Warsaw. This class is focused on the C language. I like the idea of
making a student software project based on bdwgc and contemplated
options such as
- implementation of alternative gc algorithm
- some optimizations/improvements in the current code
- building an additional tool conceptually related to bdwgc
The final project should not exceed 2000-3000 lines.

Maybe this is a stupid idea in the sense that in your view this is a
too tough assignment - please feel free to inform me about it.
Otherwise, I would be glad to hear some specific recommendations from
the authors!

Yours, Henryk Michalewski
--
http://www.mimuw.edu.pl/~henrykm
_______________________________________________
bdwgc mailing list
***@lists.opendylan.org<mailto:***@lists.opendylan.org>
https://lists.opendylan.org/mailman/listinfo/bdwgc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



This message has been scanned for malware by Websense. www.websense.com
Alexander Herz
2015-04-23 13:30:31 UTC
Permalink
Raw Message
Hi guys,

I just ran some code that uses boehm on a new machine (Linux
serverseidl6 3.13.0-27-generic #50-Ubuntu SMP Thu May 15 18:06:16 UTC
2014 x86_64 x86_64 x86_64 GNU/Linux) and the program terminates with
SIGXCPU (below is the backtrace of the core dump). I know the collector
uses these signals to interact with the threads but I fail to understand
how this signal can ever propagate so as to kill the application. Any
ideas?

Thx,
Alex

Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `./tmp/test.run'.
Program terminated with signal SIGXCPU, CPU time limit exceeded.
#0 0x00007fc2ecb03062 in do_sigsuspend (set=0x7fc2edb10980
<suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
31 ../sysdeps/unix/sysv/linux/sigsuspend.c: Datei oder Verzeichnis
nicht gefunden.
(gdb) backtrace
#0 0x00007fc2ecb03062 in do_sigsuspend (set=0x7fc2edb10980
<suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:31
#1 __GI___sigsuspend (set=***@entry=0x7fc2edb10980
<suspend_handler_mask>) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
#2 0x00007fc2ed8f21a2 in GC_suspend_handler_inner
(sig_arg=***@entry=0x1e <error: Cannot access memory at address
0x1e>, context=***@entry=0x7fc2e4f76800) at pthread_stop_world.c:255
#3 0x00007fc2ed8f2225 in GC_suspend_handler (sig=30, info=<optimized
out>, context=0x7fc2e4f76800) at pthread_stop_world.c:186
#4 <signal handler called>
#5 syscall () at ../sysdeps/unix/sysv/linux/x86_64/syscall.S:37
#6 0x00007fc2edd65673 in futex_wait (comparand=2, futex=0x7fc2ea15be2c)
at ../../include/tbb/machine/linux_common.h:60
#7 P (this=0x7fc2ea15be2c) at ../../src/tbb/semaphore.h:206
#8 commit_wait (c=<synthetischer Zeiger>, this=0x7fc2ea15be20) at
../../src/rml/include/../server/thread_monitor.h:259
#9 tbb::internal::rml::private_worker::run (this=0x7fc2ea15be00) at
../../src/tbb/private_server.cpp:280
#10 0x00007fc2edd65699 in
tbb::internal::rml::private_worker::thread_routine (arg=<optimized out>)
at ../../src/tbb/private_server.cpp:226
#11 0x00007fc2ed8f0663 in GC_inner_start_routine (sb=<Fehler beim Lesen
der Variable: value has been optimized out>, arg=<Fehler beim Lesen der
Variable: value has been optimized out>)
at pthread_start.c:56
#12 0x00007fc2ed8eb378 in GC_call_with_stack_base (fn=<optimized out>,
arg=<optimized out>) at misc.c:1597
#13 0x00007fc2ece99182 in start_thread (arg=0x7fc2e4f77700) at
pthread_create.c:312

Loading...