SBCL Internals The pages on this CLiki-driven site can be edited by anybody at any time. No warranty of any kind can therefore be made; any implied warranties of merchantability or fitness for a particular purpose are expressly disclaimed

GENCGC on PPC

GENCGC is the generational conservative garbage collector, which currently only runs on x86, x86-64 and PowerPC platforms.

Some of the benefits to gencgc are that older (long-lived) items may be copied less by using multiple generations of objects and that the gencgc is threadsafe, unlike the (current implementation of? or is it unthreadsafe by design?) Cheney GC. Also, gencgc has per-thread nursery areas, so an allocation does not stop the world like Cheney GC would have to.

Status update, 2006/02/22

The GENCGC/PPC work has been merged into the main tree. There are some notes regarding the porting effort in doc/internals-notes/GENCGC-PORTING-NOTES in the SBCL source tree. Enjoy.

Status update, 2006/02/17

It works! The latest patch can be found here and now works on Mac OS X and linux/ppc. Check sbcl-devel for more details.

Open Problems

1. None, really. There's one issue with a currently unused fixup offset that was only halfway implemented (in generic.lisp (oh, and the code for calculating the :ha offset here is wrong. we need to take into account the sign extension that will happen with the :l part is loaded), the missing bit goes in ppc-vm.lisp). But other than that, it seems good to go.

Resolved Problems

1. FIXED. Purify fails. Running the core-test.sh test causes a BUS ERROR. Thanks to jsnell for the pointer to the x86-64 approach to calling enter-alien-callback. There were actually two problems here. First, purify wasn't working properly. Second, once that was fixed, we could save the core OK, but when we loaded it and tried to call the alien-callback saved in the core we were getting a bus error. Both of these have been fixed.
2. FIXED. callback.impure.lisp test fails. something weird is happening here when we try to call qsort. perhaps we're moving things out from under the C routine? or perhaps there are still problems with calling alien routines. We were using load-symbol which expects null-tn to be wired to nil-value, which it usually is when we're coming from lisp, but isn't guaranteed to be so and is unlikely to be so when coming from C. By using nil-value instead, we avoid the problem.
3. FIXED. finalize.test.sh fails. Apparently things aren't getting finalized properly. following David Lichtblau's suggestion, I went back and revisited the weak pointer scavenging in gencgc.c. Removed the LISP_FEATURE_X86[_64] and things work again. I had done this at point, but put in back in trying to get things to work on forgot about it.
4. FIXED. cons-madly test (gc.impure.lisp) fails and drops into LDB. piso on #lisp was kind enough to point out that I should try cons-madly with non-large-objects. Sure enough, the test passes. So it looks like there are some problems allocating large objects, which are defined as any allocation greater than 4X PAGE_SIZE, which has been bumped to 32K in gencgc/ppc. The fix was to leave the pseudo-atomic bits of reg_alloc/alloc-tn and dynamic_space_free_pointer alone when updating them. This keeps the psuedo-atomic-interrupted bit from getting cloberred, which awaws preventing GC from being triggered in this context.
5. FIXED. PPC/Linux gencgc fails with a BUS ERROR (SIGSEGV maybe?) after the first GC.

Status Update - 20060208

I have ported Raymond Toy's and King Nato's changes to SBCL 0.9.9.10 and gotten gencgc to work. Sort of. A patch can be found here.

Status Update - 20060130

Now that Raymond Toy has successfully gotten GENCGC (well, GENGC, really, but more on that later) working on CMUCL/PPC, the task of porting this to SBCL/PPC should be relatively straightforward. I'm attempting to merge these changes, with some help from KingNato's branch from a couple years back. It's looking promising, and I hope to have a patch ready to go soon that either works or should get things close to working and to the point where folks who understand this stuff better than I do can help track down the remaining issues. - Cyrus

A partial list of the things that (I assume, please correct as needed!) need to happen in order to port GENCGC to PPC are:

Things that need to be done

• fpu_save and fpu_restore need to be written -- or stubbed out. It looks like we're only using these for some verbose reporting. I don't know if this is an issue on PPC at all. Do we need to save some cr's here or something? or can we just ignore this one altogether?
• purify.c conditionals need to be cleaned up as the use of dynamic_space_free_pointer is governed by (some) x86/x86-64-specific conditionals.
• some of the x86/x86-64-specific code in thread.c probably needs to either be run on ppc or have counterparts written that can run on. This is probably more of an issue for threads than for gencgc, but it seems that they are pretty tightly coupled and as long as we're doing the gencgc stuff, we should try to get as much thread-goodness along the way
• update_x86_dynamic_space_free_pointer needs to be generalized, or a counterpart for ppc written
• figure out what to about the differences in pseudo-atomic between gencgc and cheneygc platforms. do we try to make the gencgc code conform to the current p-a approach, or do we change how p-a is implemented to match the x86 and x86-64 style, or both?

Things that (probably) DON'T need to be done

• ppc specific fixups for compiled code (Can someone better describe this or point to a page that describes what fixups are?). This looks like the hairiest bit. From what I (NJF) can tell, fixups are probably not necessary on non-x86 implementations of GENCGC. Referencing constant objects in compiled code on x86 is done by means of absolute addressing, whereas on register-rich platforms, it's done by indexing off reg_CODE (or is it reg_FDEFN?). Therefore, fixups are needed when code objects move, as the absolute addresses need to be changed as well.

KingNato's gencgc branch

A while back KingNato on #lisp made a branch for a ppc gencgc. I'm not sure what the status of this is, but I think it was never finished. Some of the underlying gencgc code (x86 and x86-64) has been cleaned up since the branch point, so some work would certainly be required to migrate kingnato's changes forward to the head.

kingnato's branch was made off of 0.8.3.90. Some of the things that were changed in the branch are:

• Allocation for bignums and arrays
• allocation macro added to macros.lisp
• use clr/set_pseudo_atomic_xxx functions
• moved interrupt scavenging code from checneygc.c to gc-common.c
• use dynamic_space_free_pointer for atomic_atomic and atomic_interrupted - is this legit? Don't these have to be in reg_ALLOC and reg_NL3?
• added #define PAGE_BYTES 4096 and lots of changes in the code to replace 4096 with PAGE_BYTES. Ok, looks like this has made it onto the head. It seems like a lot of the changes on the branch are from this change.
• ... more to come ...

This page is linked from: GENCGC-ppc-porting-committee   Threading-ppc  

CLiki pages can be edited by anyone at any time. Imagine a fearsomely comprehensive disclaimer of liability. Now fear, comprehensively