After running a large join, the impalad process might have allocated tens of GB of memory. When the query finishes, all of this memory is deallocated, and the background MaintenanceThread sees that the heap size is much larger than the actual in-use memory, and calls MallocExtension::instance()->ReleaseFreeMemory(). Inside tcmalloc, this holds a global heap lock while unmapping all of the requested memory.
In one case on my cluster, releasing ~100G of memory caused the tcmalloc page lock to be held for more than 15 seconds. This caused another query to fail with Kudu scan timeouts. Outside the context of Kudu, it's likely still problematic for latency-sensitive SLAs.