2010-11-05 07:07:36     libgc: Garbage Collector

Document created by Aaronwu Employee on Aug 23, 2013
Version 1Show Document
  • View in full screen mode

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

Attachments

    Outcomes