Pure space and overflow question

Pure space and overflow question

[Andrea Corallo]

Hi all,

I'm going to take a look to pure space overflow into the native-comp
branch that happen depending on the compile configuration.  This is
maybe just due to the fact that comp.el is preloaded but anyway:

Looking at
https://www.gnu.org/software/emacs/manual/html_node/elisp/Pure-Storage.html
my understanding is that when pure space is overflowed no garbage
collection happen anymore.

But I'm running an Emacs where I can evaluate:

pure-space-overflow -> t

(garbage-collect) -> ((conses 16 1469392 534996) ....)

gc-elapsed -> 107.396662957

Is this expected?

Thanks

  Andrea

-- 
akrl@sdf.org

Re: Pure space and overflow question

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Date: Thu, 20 Feb 2020 18:04:04 +0000
> 
> Looking at
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Pure-Storage.html
> my understanding is that when pure space is overflowed no garbage
> collection happen anymore.
> 
> But I'm running an Emacs where I can evaluate:
> 
> pure-space-overflow -> t
> 
> (garbage-collect) -> ((conses 16 1469392 534996) ....)
> 
> gc-elapsed -> 107.396662957
> 
> Is this expected?

If your Emacs was pdumped, yes.

Re: Pure space and overflow question

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is this expected?
>
> If your Emacs was pdumped, yes.
>

Right, I see now the updated doc in the info page of the branch.

Thanks!

Andrea

-- 
akrl@sdf.org

Re: Pure space and overflow question

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Date: Thu, 20 Feb 2020 18:04:04 +0000
>>
>> Looking at
>> https://www.gnu.org/software/emacs/manual/html_node/elisp/Pure-Storage.html
>> my understanding is that when pure space is overflowed no garbage
>> collection happen anymore.
>>
>> But I'm running an Emacs where I can evaluate:
>>
>> pure-space-overflow -> t
>>
>> (garbage-collect) -> ((conses 16 1469392 534996) ....)
>>
>> gc-elapsed -> 107.396662957
>>
>> Is this expected?
>
> If your Emacs was pdumped, yes.
>

If just a specific configuration needs a little more pure space what's
the way we prefer to handle this?

- Define SYSTEM_PURESIZE_EXTRA from the the configure.ac

- Just change SYSTEM_PURESIZE_EXTRA in puresize.h (as the doc says)

- Change it there but with an ifdef only for the specific configuration

- Something else?

Thanks

  Andrea

--
akrl@sdf.org

Re: Pure space and overflow question

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Feb 2020 11:53:58 +0000
> 
> If just a specific configuration needs a little more pure space what's
> the way we prefer to handle this?
> 
> - Define SYSTEM_PURESIZE_EXTRA from the the configure.ac
> 
> - Just change SYSTEM_PURESIZE_EXTRA in puresize.h (as the doc says)
> 
> - Change it there but with an ifdef only for the specific configuration
> 
> - Something else?

IMO, SYSTEM_PURESIZE_EXTRA is for specific _platforms_.  So if a
specific configuration on some platform needs more pure space, but
other configurations on the same platform do not, that specific
configuration should conditionally enlarge BASE_PURESIZE.

That said, why does your configuration require more pure space than
any other on that same platform?

Re: Pure space and overflow question

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

> IMO, SYSTEM_PURESIZE_EXTRA is for specific _platforms_.  So if a
> specific configuration on some platform needs more pure space, but
> other configurations on the same platform do not, that specific
> configuration should conditionally enlarge BASE_PURESIZE.

Okay

> That said, why does your configuration require more pure space than
> any other on that same platform?

Effectively in comp.c are allocate object that goes into pure space and
all the code is under #ifdef HAVE_NATIVE_COMP.

Also the constant objects present in every compilation unit can have a
small overhead respect to the elc one.  This is because they include the
data used by the 'top_level_run' function.

We could split this but personally I'm not sure is worth to complexify
the design to save some KBs of configuration specific pure space.

Thanks

  Andrea

--
akrl@sdf.org

Re: Pure space and overflow question

[Eli Zaretskii]

> From: Andrea Corallo <akrl@sdf.org>
> Cc: emacs-devel@gnu.org
> Date: Fri, 21 Feb 2020 13:54:42 +0000
> 
> > That said, why does your configuration require more pure space than
> > any other on that same platform?
> 
> Effectively in comp.c are allocate object that goes into pure space and
> all the code is under #ifdef HAVE_NATIVE_COMP.
> 
> Also the constant objects present in every compilation unit can have a
> small overhead respect to the elc one.  This is because they include the
> data used by the 'top_level_run' function.

Do you really need the former to be pure, and to be dumped in general?
If so, why?

I think with portable dumper in place, we should have a more
fine-grained distinction between the stuff that really needs to be
dumped, and stuff that just happens to be there due to code that runs
at loadup time.  The latter should not be dumped, but instead should
be re-created anew in every Emacs session.  In particular, stuff that
is needed for compilation should ideally not even be in memory until
the user wants to compile something.

Am I missing something?

Re: Pure space and overflow question

[Andrea Corallo]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Andrea Corallo <akrl@sdf.org>
>> Cc: emacs-devel@gnu.org
>> Date: Fri, 21 Feb 2020 13:54:42 +0000
>> 
>> > That said, why does your configuration require more pure space than
>> > any other on that same platform?
>> 
>> Effectively in comp.c are allocate object that goes into pure space and
>> all the code is under #ifdef HAVE_NATIVE_COMP.
>> 
>> Also the constant objects present in every compilation unit can have a
>> small overhead respect to the elc one.  This is because they include the
>> data used by the 'top_level_run' function.
>
> Do you really need the former to be pure, and to be dumped in general?
> If so, why?
>
> I think with portable dumper in place, we should have a more
> fine-grained distinction between the stuff that really needs to be
> dumped, and stuff that just happens to be there due to code that runs
> at loadup time.  The latter should not be dumped, but instead should
> be re-created anew in every Emacs session.  In particular, stuff that
> is needed for compilation should ideally not even be in memory until
> the user wants to compile something.
>
> Am I missing something?

No you are not, effectively immediate objects into 'top_level_run' don't
have to stay necessarily into pure space because once the file is loaded
and emacs is dumped 'top_level_run' has no reason to be execute ever
again.  In this sense is a very special function.

I've added a special variable to impose that objects are emitted as
'impure' (never copied to pure space).  Binding this to t while emitting
the code for 'top_level_run' does the job.

This is sufficient to stay in the current pure space size (at least for
my current X configuration).  I'll be pushing it when finished with
the tests.

Thanks

  Andrea

-- 
akrl@sdf.org