[Gc] [m-dev.] Mercury and GCC split stacks

[Paul Bone]

Hi,
Has anyone tried Mercury (particularly the high-level C grades) with
GCC's split stacks capability? See: <https://gcc.gnu.org/wiki/SplitStacks>.

The trade offs seem interesting, not that they're trying to economise on
address space usage, especially on 32bit systems. On a 64bit system this
isn't a big deal for C programs as only the parts of the stack that actually
get used get mapped to actual physical pages.

There may also be interesting interactions with the Boehm collector. Will
BoehmGC be able to scan these stacks?

I've cross-posted this to the Boehm GC list as it may be interesting for
the GC's developers.

[Hans Boehm]

I think this will require work to correctly scan such stacks. AFAIK, the
collector currently assumes that thread stacks are contiguous. The current
thread stopping code may also need work to perform reasonably for large
numbers of (hopefully mostly blocked) threads.

Hans

Hi,
Has anyone tried Mercury (particularly the high-level C grades) with
GCC's split stacks capability? See: <

https://gcc.gnu.org/wiki/SplitStacks>.
The trade offs seem interesting, not that they're trying to economise on
address space usage, especially on 32bit systems. On a 64bit system this
isn't a big deal for C programs as only the parts of the stack that actually
get used get mapped to actual physical pages.
There may also be interesting interactions with the Boehm collector. Will
BoehmGC be able to scan these stacks?
I've cross-posted this to the Boehm GC list as it may be interesting for
the GC's developers.
--
Paul Bone
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc

[Paul Bone]

Post by Hans Boehm
I think this will require work to correctly scan such stacks. AFAIK, the
collector currently assumes that thread stacks are contiguous. The current
thread stopping code may also need work to perform reasonably for large
numbers of (hopefully mostly blocked) threads.

This was my guess but I didn't know if the GC already had support.

Thanks for your reply.

[Bruce Hoult]

Requires work, but not difficult work.

If you've implemented your own threads then presumably you can figure out
how to stop them and plumb that into GC_stop_world() (or make the
STOP_WORLD() macro call an entirely different function of your choice)

Similarly, if your stacks are not contiguous, you'll also know how to
enumerate the various sections of them. Then it's only a matter of
setting GC_push_other_roots_proc (by calling GC_set_push_other_roots()) to
a function that knows how to find all the sections of all the thread
stacks. GC_push_other_roots_proc is called once at the start of every GC,
so it is ideal for things such as stacks that are likely to be different
sizes and locations at every GC.

See the comments in include/private/gc_priv.h

Post by Hans Boehm
I think this will require work to correctly scan such stacks. AFAIK, the
collector currently assumes that thread stacks are contiguous. The current
thread stopping code may also need work to perform reasonably for large
numbers of (hopefully mostly blocked) threads.
Hans

Hi,
Has anyone tried Mercury (particularly the high-level C grades) with
GCC's split stacks capability? See: <

https://gcc.gnu.org/wiki/SplitStacks>.
The trade offs seem interesting, not that they're trying to economise on
address space usage, especially on 32bit systems. On a 64bit system this
isn't a big deal for C programs as only the parts of the stack that actually
get used get mapped to actual physical pages.
There may also be interesting interactions with the Boehm collector. Will
BoehmGC be able to scan these stacks?
I've cross-posted this to the Boehm GC list as it may be interesting for
the GC's developers.
--
Paul Bone
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc

--
This message has been scanned for viruses and
dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
believed to be clean.
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc