On garbage file:
There are several possibilities I can think of. The first is simply a "dump" file. This is usually a debug routine which is a dump of system RAM states at the point of failure. RAM stores all of the information the computer is working on. Depending on how the program is keyed, this could be all of what is stored in system RAM, or just the CPU stack and the cache RAM. Since programs can run over a gigabyte and store many values in RAM, most dumps are of the cache RAM and process stack.
Meltdown and spectre used exploits of CPU virtualization to break down the barriers that usually prevent a program from accessing memory that doesn't belong to it. This keeps a program running on your web browser from looking down into the locations where a cryptography key your computer is using for SSL (or the routine which has replaced it, SSL is no longer considered secure). Since these programs were able to break down virtualization at the hardware level for certain models of CPU, it was a noteworthy problem, particularly for web servers which may run several different webpages from several different clients. An infection of one webpage for a local tea club could be dumping financial information from a small e-store hosted from the same server.
The other garbage file has to do with "garbage collection." In programming languages, there is a concept known as garbage collection, which is where you release a location in memory to use after a process/task is done with it. It's kind of like closing a window you aren't using or tossing a piece of scratch paper in the trash so it isn't on the table.
Many "modern" languages, Java and C#, for example, use automatic garbage collection. Programmers using these languages do not often think much on what is done with their variables and processes after they have completed. These processes can be everything from fields for string entry to raster or vector renders.
I am not familiar with how garbage collection in these languages works (never liked the concept, myself - encourages sloppy programming), but it is possible that this garbage collection process could be exploited to read things that are not supposed to remain in memory. This, again, ties somewhat back into Spectre and Meltdown, as they were able to manipulate CPU cycles to sneak reads from memory addresses that should have been removed. If this was done at the process level, however - an entire host of garbage collection strategies deliberately sabotaged to allow for easier reading… Then the implications of Spectre and Meltdown are dire for the programming world and will require a complete re-thinking of how programs are authored and how system calls are integrated into programming languages.