From: Sam S. <sd...@gn...> - 2008-11-05 14:36:22
|
Hi Vladimir, Vladimir Tzankov wrote: > On Nov 4, 2008, at 7:55 PM, Sam Steingold wrote: >> Vladimir Tzankov wrote: >>> For example it wants to malloc 0x400004190 bytes of memory (bit(31) >>> *8 + more for the other levels) during bootstrap. It's not >>> acceptable on any invocation of printer to execute such thing. >>> Still thinking :). >> could it be that increasing the number of levels (from 6 to 10, to >> match the number of levels for the first 32 bits) is the solution? > > I do not think this will help. As read the code - mlb_add() will > always try to allocate bitmap for all possible addresses (correct me > if I am wrong). > > Also I do not like the malloc() calls. I am looking now on the "old" > implementation that uses gc marks. > get_circ_mark() / get_circ_unmark() / subst_circ_mark() / > subst_circ_unmark() cannot be interrupted by the GC (they do not do > allocation or perform GC_SAFE calls). So it is safe to use marking > from GC point of view. > If the mark is per thread - than there will be no problems with > different threads executing simultaneously these functions. > > Here some thoughts. Correct me if I am wrong. > > Currently every object on the heap start with GCSelf (32 or 64 bits) > which is used only during GC (with exception of Symbols that use it > for flags in some builds). > Can we use these bits for marking per thread combined with a > semaphore (with count - the number of available bits)? I see no problem off hand, but I have not thought about it carefully yet. Bruno, WDYT? > In this way we can allow concurrent circular detection for up to XX > threads (XX = 32/64 minus bits reserved for symbol flags). I don't think this is necessary since circularity detection happens only in READ which has to lock all the packages anyway (I don't think we can afford acquiring a lock for each INTERN). |