I did some rough calculations yesterday of the size of things like BURS tree nodes and space efficient graph nodes in the opt compiler. A BURS tree node needs about 71bytes of memory, which will get rounded up to 74bytes. A space efficient graph node is about 48bytes in size. With headers and alignment we possibly push the total size to around 138bytes. In LIR to MIR we will create a space efficient graph node and BURS tree node per instruction, with the IR containing between 100 and a few thousand instructions this could push the amount of space requested into the region of 100s of kb.
A generational GC should recognize that nearly of this is junk and bin it. But for some benchmarks (like Jython that has large basic blocks just containing calls) we may be overflowing the nursery. It would be good if it were some how possible to monitor the opt compiler doing bad things to the GC. This would help identify if strange performance of the opt compiler were down to GC (and then we can fix the size of the opt compiler IR).