[WIP] CoreToStg: Try treating String unpackings as single-entry
Needs RevisionPublic

Authored by bgamari on May 20 2018, 6:46 PM.


Trac Issues

This is a quick attempt of the idea proposed in Trac #15113, making top-level
bindings whose RHS is an application of a string unpack operation (e.g.
unpackCString#) single-entry. While this reduces sharing of the unpacked
[Char]s, it significantly reduces the number of CAFfy bindings in a typical
program (see Trac #15038).

bgamari created this revision.May 20 2018, 6:46 PM
bgamari retitled this revision from CoreToStg: Try treating String unpackings as single-entry to [WIP] CoreToStg: Try treating String unpackings as single-entry.May 20 2018, 6:47 PM
bgamari updated the Trac tickets for this revision.Jun 17 2018, 11:36 AM
simonpj added inline comments.

Hang on: you are doing this in mkStgRhs which is used for *non-top-level* let-bindings. It may be worth doing it there too, but the ticket refers to *top-level* bindings, which are done by mkTopStgRhs!!!

bgamari added inline comments.Jun 18 2018, 8:40 AM

Yikes, good catch!

bgamari updated this revision to Diff 16999.Jun 18 2018, 8:43 AM

Handle top-level case as well

alpmestan requested changes to this revision.Aug 22 2018, 8:25 AM
alpmestan added a subscriber: alpmestan.

The patch looks good, but Note [String unpack closures are non-updateable] has yet to be written.

This revision now requires changes to proceed.Aug 22 2018, 8:25 AM

Also don't forget to try the other variants mentioned in comment:5 of Trac Trac #15113

osa1 added a subscriber: osa1.Oct 1 2018, 9:37 AM

This patch does not work as intended because it's too late to change CAFFY-ness of definitions in CoreToStg (remember that CAFFYness of things are computed in CorePrep, which happens before CoreToStg).

Another option might be to keep top-level strings updatable, but make the GC revert the CAF. That way we would get some of the sharing back.

osa1 added a comment.Oct 2 2018, 1:54 AM

Could you say a few more words on reverting a CAF? An evaluated CAF becomes an IND_STATIC, right? Do you mean we could somehow save the old info ptr and somehow scavenge the CAF using the old info ptr? (rather than scavenging it as IND_STATIC?)

@osa1 We save the old info pointer when entering a CAF: https://phabricator.haskell.org/diffusion/GHC/browse/master/rts%2Fsm%2FStorage.c$406

This is currently to support GHCi's CAF-reverting feature, but it could be used to revert CAFs in other cases too.