[Top][All Lists]

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

Re: [RFC] temporary Lisp_Strings

From: Paul Eggert
Subject: Re: [RFC] temporary Lisp_Strings
Date: Tue, 02 Sep 2014 07:37:18 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

What would the GC do when it sees such a string? Wouldn't this make the GC a bit less robust, as it couldn't diagnose bogus strings any more when GC_CHECK_MARKED_OBJECTS is defined?

Like Stefan, I wonder how much performance benefit you're really gaining here. Presumably most of it is lack of pressure on the GC, and how do you measure that?

I assume you're thinking of eventually doing this for conses etc. too?

Dmitry Antipov wrote:
is there a way to make sure that an address returned by alloca fits in 

It should work on typical platforms, as alloca should return an address that is aligned well enough for Emacs, just as malloc does. Perhaps we may run into an oddball platform where alloca isn't suitably aligned, but if so we can simply allocate a few more bytes than needed and then align the pointers ourselves. For starters, though, I'd just assume that it's aligned. An Emacs built with ENABLE_CHECKING should verify any alignment issues already, as make_lisp_ptr checks for this.

We don't need to worry about !USE_LSB_TAG on the trunk anymore, as support for abusing the high-order bits of pointers has been withdrawn on the trunk.

reply via email to

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