2010-11-05 07:07:36 libgc: Garbage Collector
Morten Kvistgaard (DENMARK)
Message: 95592
Hello there,
I'm just adding piece of investigation results for the shared uClinux Blackfin memory
libgc is a widely used lib for garbage collecting in ANSI C and C++: www.hpl.hp.com/personal/Hans_Boehm/gc/
It's even included in the GNU compiler distribution. It's been ported for a *lot* of different platforms and systems. Including ones that uses the uclibc. So it ought not be that difficult to port to Blackfin uClinux either. And I can almost make it work I think. (But not quite.)
If someone should take an interest, some of my attempts have been recorded in this maillist: www.hpl.hp.com/hosted/linux/mail-archives/gc/2010-November/004190.html
With the newest version of the libgc I end up with a "Data access CPLB miss" exception from their unit test. And various tests with setting the stack size, stack checks, mudflap and debugging, hasn't shown anything of interest. I assume that you have to have a bit more insight in the FLAT compiler and format than I do.
This is the CPLB exception:
root:~> ./gctest Data access CPLB miss
<5> - Used by the MMU to signal a CPLB miss on a data access.
Deferred Exception context
CURRENT PROCESS:
COMM=gctest PID=351 CPU=0
TEXT = 0x02a80040-0x02a905c0 DATA = 0x02a905e0-0x02a92f54
BSS = 0x02a92f54-0x02ab6880 USER-STACK = 0x02ab7f74
return address: [0x02a89b5a]; contents of:
0x02a89b30: 29e4 9111 6408 5208 0a02 102a e120 0457
0x02a89b40: 4150 e14a 02aa e10a 7154 3208 5a8a 9150
0x02a89b50: e14a 02aa e10a 7298 5e82 [9151] 0c41 1409
0x02a89b60: 3002 6009 e3ff ff6c e3ff d900 3208 2017
ADSP-BF526-0.0(Detected 0.2) 400(MHz CCLK) 80(MHz SCLK) (mpu off) Linux version 2.6.36-ADI-2011R1-pren
(mk@PCHe-Ubuntu) (gcc version 4.3.4 (ADI-trunk/git-7bbb2ed) ) #8 Wed Nov 3 15:08:52 CET 2010
SEQUENCER STATUS: Not tainted
SEQSTAT: 00060026 IPEND: 0008 IMASK: ffff SYSCFG: 0006
EXCAUSE : 0x26
physical IVG3 asserted : <0xffa00760> { _trap + 0x0 }
RETE: <0x00000000> /* Maybe null pointer? */
RETN: <0x02b56000> /* kernel dynamic memory */
RETX: <0x00000480> /* Maybe fixed code section */
RETS: <0x02a809a6> [ gctest + 0x966 ]
PC : <0x02a89b5a> [ gctest + 0x9b1a ]
DCPLB_FAULT_ADDR: <0x0d547e58> /* unconnected memory */
ICPLB_FAULT_ADDR: <0x02a89b5a> [ gctest + 0x9b1a ]
PROCESSOR STATE:
R0 : 0000117c R1 : 00000000 R2 : 00000008 R3 : 02aa980c
R4 : 02b71f30 R5 : 00001194 R6 : 00000000 R7 : 000007d4
P0 : 02aa82f0 P1 : 0000117c P2 : 0d547e58 P3 : 02b71f00
P4 : 02aa6b64 P5 : 02aa7028 FP : 02aa82a0 SP : 02b55f24
LB0: 02a8d4e5 LT0: 02a8d4e4 LC0: 00000000
LB1: 02a89523 LT1: 02a89518 LC1: 00000000
B0 : 00000000 L0 : 00000000 M0 : 00003564 I0 : 02b85000
B1 : 00000000 L1 : 00000000 M1 : 00000000 I1 : 02aa687c
B2 : 00000000 L2 : 00000000 M2 : 00000000 I2 : 00000000
B3 : 00000000 L3 : 00000000 M3 : 00000000 I3 : 00000000
A0.w: 00000000 A0.x: 00000000 A1.w: 00000000 A1.x: 00000000
USP : 02aa8294 ASTAT: 02000020
Hardware Trace:
0 Target : <0x00003f14> { _trap_c + 0x0 }
Source : <0xffa006f4> { _exception_to_level5 + 0xa4 } JUMP.L
1 Target : <0xffa00650> { _exception_to_level5 + 0x0 }
Source : <0xffa00504> { _bfin_return_from_exception + 0x18 } RTX
2 Target : <0xffa004ec> { _bfin_return_from_exception + 0x0 }
Source : <0xffa005a8> { _ex_trap_c + 0x74 } JUMP.S
3 Target : <0xffa00418> { _ex_dcplb_miss + 0x0 }
Source : <0xffa007ba> { _trap + 0x5a } JUMP (P4)
4 Target : <0xffa00760> { _trap + 0x0 }
FAULT : <0x02a89b5a> [ gctest + 0x9b1a ] P1 = [P2]
Source : <0x02a89b58> [ gctest + 0x9b18 ] 0x5e82
5 Target : <0x02a89b3c> [ gctest + 0x9afc ]
Source : <0x02a89b28> [ gctest + 0x9ae8 ] IF CC JUMP pcrel (BP)
6 Target : <0x02a89b1c> [ gctest + 0x9adc ]
Source : <0x02a809a2> [ gctest + 0x962 ] JUMP.L
7 Target : <0x02a80988> [ gctest + 0x948 ]
Source : <0x02a80a14> [ gctest + 0x9d4 ] CALL pcrel
8 Target : <0x02a80a12> [ gctest + 0x9d2 ]
Source : <0x02a80a0c> [ gctest + 0x9cc ] IF CC JUMP pcrel
9 Target : <0x02a80a00> [ gctest + 0x9c0 ]
Source : <0x02a80a20> [ gctest + 0x9e0 ] CALL pcrel
10 Target : <0x02a80a18> [ gctest + 0x9d8 ]
Source : <0x02a809c8> [ gctest + 0x988 ] RTS
11 Target : <0x02a809be> [ gctest + 0x97e ]
Source : <0x02a809aa> [ gctest + 0x96a ] IF !CC JUMP pcrel (BP)
12 Target : <0x02a809a6> [ gctest + 0x966 ]
Source : <0x02a89ba2> [ gctest + 0x9b62 ] RTS
13 Target : <0x02a89b9c> [ gctest + 0x9b5c ]
Source : <0x02a89b8c> [ gctest + 0x9b4c ] JUMP.S
14 Target : <0x02a89b70> [ gctest + 0x9b30 ]
Source : <0x02a89b5e> [ gctest + 0x9b1e ] IF !CC JUMP pcrel (BP)
15 Target : <0x02a89b3c> [ gctest + 0x9afc ]
Source : <0x02a89b28> [ gctest + 0x9ae8 ] IF CC JUMP pcrel (BP) Userspace Stack Stack info:
SP: [0x02aa8294] <0x02aa8294> [ gctest + 0x28294 ] Memory from 0x02aa8290 to 02aa9000
02aa8290: 00000000 [00000000] 00000000 00000000 02aa82b4 02a809a6 00000438 00010fa0
...
Return addresses in stack:
address : <0x00001194> { _init_post + 0x8 }
...
BUS
QuoteReplyEditDelete
2010-11-05 16:48:58 Re: libgc: Garbage Collector
Robert Cochran (UNITED STATES)
Message: 95598
Morten,
I'm curious about your motivation for this library on the nommu Blackfin. Are you mainly interested in the garbage collector for the sake of code simplicity & robustness (not needing to track your allocations), or are you looking for a better method in managing overall memory allocation & reclamation in your embedded system?
Could this library somehow better manage the non virtual memory on Blackfin? Could the library give you a better ability to manage the holes created in memory during the life of your system?
Thanks,
Bob
QuoteReplyEditDelete
2010-11-07 23:37:36 Re: libgc: Garbage Collector
Sonic Zhang (CHINA)
Message: 95622
You can build it with -g flag and track the crash by gdb.
QuoteReplyEditDelete
2010-11-08 05:13:34 Re: libgc: Garbage Collector
Morten Kvistgaard (DENMARK)
Message: 95639
My main interest in gc, is simplicity, robustness and productivity. I hadn't actually considered that it might be better at overall memory handling than the Blackfin it self...
Anyway, garbage collection is considered (by many) to be the biggest innovation of all time, in regard to programmer productivity. Eventual gains in OO vs. non-OO vs. Functional vs. Actor etc. does not even come close when compared to automatic garbage collection vs. manual.
There's also the robustness and functional safety issue. MISRA C is nowhere near a substitute for "Contract based programming, with garbage collection". And yet it seems to be the only realistic choice in Blackfin uClinux development. (Eiffel might be able to create BF userspace programs.)
But I'm just researching options. Garbage Collecting in C/C++ would've been an interesting experiment.
QuoteReplyEditDelete
2010-11-08 10:40:00 Re: libgc: Garbage Collector
Wojtek Skulski (UNITED STATES)
Message: 95645
Morten:
I hope that I will not offend anyone when I agree with your statement "garbage collection is considered (by many) to be the biggest innovation of all time". My own experience supports such a statement 200%. Over last 15 years I have been using Oberon family of languages (Oberon System from ETH Zurich en.wikipedia.org/wiki/Oberon_(operating_system) and Component Pascal from www.oberon.ch/blackbox.html). My productivity gain over C/C++ was tenfold. I could rapidly complete enormously complex scientific projects in Component Pascal in a small fraction of the effort it takes me to complete anything in C.
I am dreaming of Oberon System running on Blackfin on top of Linux kernel. It would be an unbelievable improvement over the current development mode. Just think of freedom from any memory leaks, all variable assignments always being correct, never corrupt any memory, dynamically load and unload modules, compile your entire project in a fraction of a second, and source-code portability between Windows/Linux//Mac/PowerPC/MIPS/Sun. It may sound like a heresy to some that such complete portability was demonstrated fifteen years ago and happily ignored by the programming industry.
I wish you good luck, but I am not optimistic. The current mindset in computer programming is favoring gdb.
-- W.
QuoteReplyEditDelete
2010-11-08 21:58:51 Re: libgc: Garbage Collector
Mike Frysinger (UNITED STATES)
Message: 95667
i dont think the FLAT file format would be a source of errors here. if you built things as FDPIC ELF, you might get a better trace as it would show the split between the uClibc libraries, the libgc libraries, and the main app itself.
since you have the gctest binary, your system is the only one that can figure out what the trace means:
docs.blackfin.uclinux.org/doku.php?id=uclinux-dist:analyzing_traces
about the only thing we can tell you is that the code in question is indeed executing incorrectly. from the trace:
FAULT : <0x02a89b5a> [ gctest + 0x9b1a ] P1 = [P2]
...
P2 : 0d547e58
...
DCPLB_FAULT_ADDR: <0x0d547e58> /* unconnected memory */
ICPLB_FAULT_ADDR: <0x02a89b5a> [ gctest + 0x9b1a ]
...
QuoteReplyEditDelete