unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* MPS question: small object allocation
@ 2024-06-26 14:31 Daniel Colascione
  2024-06-26 15:20 ` Gerd Möllmann
  0 siblings, 1 reply; 2+ messages in thread
From: Daniel Colascione @ 2024-06-26 14:31 UTC (permalink / raw)
  To: emacs-devel

I'm catching up on the MPS branch.  I'm super excited to see Emacs get a
modern GC.  (I regret that I never found time to finish my
attempt from a few years ago.) It looks like MPS supports both manual
memory management by pool and automatic garbage collection.  Is there
anything that might help us deal with the problem of having tons of
small objects?  In a traditional JVM-style GC, each object begins with a
type-word of some sort (sometimes inflated for locking, etc.)  This
approach is inefficient for small objects: a cons cell, for example,
would have 50% overhead, because it'd have to have one machine word for
the type, then two machine words for car and cdr.  Does MPS have a way
to eliminate this per-object overhead for objects like cons cells,
markers, and so on?



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: MPS question: small object allocation
  2024-06-26 14:31 MPS question: small object allocation Daniel Colascione
@ 2024-06-26 15:20 ` Gerd Möllmann
  0 siblings, 0 replies; 2+ messages in thread
From: Gerd Möllmann @ 2024-06-26 15:20 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

Daniel Colascione <dancol@dancol.org> writes:

> I'm catching up on the MPS branch.  I'm super excited to see Emacs get a
> modern GC.  (I regret that I never found time to finish my
> attempt from a few years ago.) It looks like MPS supports both manual
> memory management by pool and automatic garbage collection.  Is there
> anything that might help us deal with the problem of having tons of
> small objects?  In a traditional JVM-style GC, each object begins with a
> type-word of some sort (sometimes inflated for locking, etc.)  This
> approach is inefficient for small objects: a cons cell, for example,
> would have 50% overhead, because it'd have to have one machine word for
> the type, then two machine words for car and cdr.  Does MPS have a way
> to eliminate this per-object overhead for objects like cons cells,
> markers, and so on?

Hi Daniel,

MPS can support that, by allocating conses, as one example, from an MPS
pool that contains conses only. Igc doesn't do that ATM, all objects,
including conses, have the same 1 word header as other objects.

And it will be a ton of work to remove the header for some objects. Hash
tables for example: the igc_header also contains an address-independent
hash. When that is no longer the case for all objects, we need to
reimplement hash tables using an MPS feature that exists for that
purpose (location dependency).

And that's no fun at all, so it's something in search of an implementor
:-).



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2024-06-26 15:20 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-06-26 14:31 MPS question: small object allocation Daniel Colascione
2024-06-26 15:20 ` Gerd Möllmann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).