|
Re: HEADSUP: Generational GC for Sparc: msg#00292lisp.cmucl.devel
>>>>> "Raymond" == Raymond Toy <toy@xxxxxxxxxxxxxxx> writes: Raymond> There is one potential problem though. To get this to work, I had to Raymond> disable this gc_assert in scav_hash_vector in gencgc.c: Raymond> gc_assert (where == (lispobj *) PTR (hash_table->table)); I've done some testing with this gencgc and this invariant does actually hold, but not during scavenging. I put a hook on *after-gc-hooks* that grovels over the static and dynamic spaces looking for hash tables where hash-table-table wasn't EQ to the hash-table object itself (which is what the assertion above is checking). After building CMUCL 3 times with itself and CLX, Hemlock, CLM, there were no cases where the assertion didn't hold. My guess is that the hash-table-table gets moved before we get around to scavenging the hash-table itself. Whew! This makes me feel better about gencgc on Solaris. So sometime in the near future, I'm going to remove the assertion (for sparc) and the extraneous messages that were getting printed. Ray |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: [HEADS UP} dynamic-extent merged: 00292, Raymond Toy |
|---|---|
| Next by Date: | Apparent CMU CL compiler bug: 00292, Gareth McCaughan |
| Previous by Thread: | Re: HEADSUP: Generational GC for Sparci: 00292, Matt Curtin |
| Next by Thread: | No space left on device: 00292, Raymond Toy |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |