[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 9227864: Further fix for aborts due to GC losing pseudovector

From: Pip Cet
Subject: Re: master 9227864: Further fix for aborts due to GC losing pseudovectors
Date: Tue, 26 May 2020 17:25:38 +0000

On Tue, May 26, 2020 at 2:51 PM Stefan Monnier <address@hidden> wrote:
> > Oh, you're right. No harm so far since LISP_ALIGNMENT is 8 on current 
> > platforms.
> For 64bit float, a LISP_ALIGNMENT greater than 8 would imply
> a significant amount of waste (same for cons cells on 32bit systems).
> So I think it'll stay at 8 for the foreseeable future (which doesn't
> mean we can't decide to use large alignment for some other objects, of
> course).

I'm hoping that if we have an allocate_aligned_pseudovector function
(or macro) we won't need LISP_ALIGNMENT at all. Which is good, since
it was misnamed (pure Lisp data and Lisp data on the stack never
obeyed LISP_ALIGNMENT. I'm suspicious about pdumper data, too, as
pdumper.c sets DUMP_ALIGNMENT to GCALIGNMENT on many practical
platforms, not LISP_ALIGNMENT). It's true that GCALIGNMENT is 1 on
some platforms, but we can change that, can't we?

I guess the recent bugs also make it impossible to do a 32-bit
--wide-int USE_LSB_TAG build. My suspicion is that that would actually
be faster, since we need only look at one 32-bit word to chase a
pointer, but it would make stack marking a lot slower...

reply via email to

[Prev in Thread] Current Thread [Next in Thread]