This isn't new with 4.4.0-rc4, it has been an issue in all of the 4.4 release candidates I tried. HELP-13660 has a possible explanation for the trigger: 1) modify many documents and then 2) do queries that require long-running scans.
My test case is Linkbench with a large database. The workload is 1) load the database 2) create a secondary index on one of the collections and 3) run transactions. The problem happens at step 2 which does a scan during create index. The test database is ~200G with Snappy compression and WiredTiger has cacheSizeGB=40.
I dump tcmalloc stats after each step. Much more detail is here and the summary is listed below.
For 4.4.0-rc4, VSZ for the mongod process is ~9G larger after create index compared to VSZ for 4.2.6 or 4.4 prior to the durable history merge.
This can be reproduced with Linkbench2 that is in DSI, although:
1) that will have to be changed to create the secondary index after the load.
2) I use maxid1=200M while the code in DSI now uses maxid1=10M
I am not sure whether Henrik added a repro to DSI for this when he did the work leading to HELP-13660