On 6/20/24 4:36 PM, Richard Biener wrote: > > >> Am 20.06.2024 um 16:05 schrieb Andrew MacLeod : >> >>  >>> On 6/20/24 05:31, Richard Biener wrote: >>>> On Thu, 20 Jun 2024, Aldy Hernandez wrote: >>>> >>>> Hi. >>>> >>>> I came around to this, and whipped up the proposed patch. However, it >>>> does seem a bit verbose, and I'm wondering if it's cleaner to just >>>> leave things as they are. >>>> >>>> The attached patch passes tests and there's no difference in >>>> performance. I am wondering, whether it's better to get rid of >>>> all/most of the local obstacks we use in ranger, and just use the >>>> global (NULL) one? >>>> >>>> Thoughts? >>> It really depends on how much garbage ranger is expected to create >>> on the obstack - the global obstack is released after each pass. >>> But ranger instances are also not expected to be created multiple >>> times each pass, right? >> >> >> Typically correct. Although the path ranger also creates a normal ranger,. Different components also have their own obstacks, mostly because they can be used independent of ranger. I didn't want to add artificial dependencies just for a obstack sharing. >> >> I was unaware of how the global one worked at that point. Do they get stacked if another global obstack is initialized? And is there any danger in that case twe could accidentally have a sequence like: >> >> obstack1 created by ranger >> GORI allocates bitmap from obstack1 >> obstack2 created by the pass that decided to use ranger >> GORI allocates bitmap2.. comes from obstack2 >> obstack2 destroyed by the pass. >> GORI tries to use bitmap2 .. its now unallocated. >> >> If so, this reeks of the obstack problems we had back in the late 90's when obstacks were generally stacked. Tracking down objects still in use from freed obstacks was a nightmare. That is one of the reason general stacked obstacks fell out of favour for a long time, and why i only ever use local named one. >> >> It seems to me that components managing their own obstacks ensures this does not happen. >> >> If, however, that is not longer a problem for some reason, then I have no strong feelings either way either. > > The global obstack is special, it’s init keeps a reference count. So yes, a local obstack is cleaner. Ok, since a local obstack is cleaner and a global one has the potential to introduce subtle bugs, I have rebased the patch against current mainline and will commit the attached if it passes tests. Thanks for everyone's feedback. Aldy