Re: MPS: weak hash tables

[Pip Cet]

On Sunday, July 7th, 2024 at 08:24, Gerd Möllmann <gerd.moellmann@gmail.com> 
wrote:
> Gerd Möllmann gerd.moellmann@gmail.com writes:
> > Helmut Eller eller.helmut@gmail.com writes:
> > > On Sun, Jul 07 2024, Pip Cet wrote:
> > > > What's going on here?
> > > 
> > > How likely is a bug in the tree balancing code? I find it rather odd
> > > that the old GC rebalances interval trees during the sweep phase.
> > 
> > I'd say not very likely but of course not impossible.
> > 
> > The problem with the interval tree is that it isn't self-balancing like
> > say a red-black tree. It isn't using an algorithm that I recognize.
> > Already when I wrote the new redisplay code it was a problem that the
> > tree sometimes degraded for which I added more calls to balance it.
> > 
> > Both string and buffer intervals are balanced in the swepp phase of the
> > old GC I see.
> > 
> > Hm, maybe we are missing out on something here, in igc. I don't remember
> > that I balance in igc.

Do we remove intervals at all with igc? It looks to me like they're 
partially-weak objects, effectively, and we scan them strongly, removing them 
only when the buffer dies?

> I've also run the slow version of the test, when it happens to be slow
> which is a mystery, under Instruments, which is kind of the shitty
> equivalent of perf on macOS.
> 
> From the little I see there, something I don't know is concatenating
> strings, and adding text properties to them. This allocates conses and
> intervals. The allocation point is running out of reserved memory,
> mps_ap_fill is called, and MPS scans like mad. That's where the time
> goes. Alone 13% of the whole time is spent in fix_cons for example.
> 
> More I can't see with the tools I have available here. Maybe intersting
> could be that balance_intervals doesn't show up here, but that could be
> due to the differences in barrier implementation on macOS.
> 
> And the good question is of course why is the test fast when invoked
> like Pip showed?

Well, the backtrace that's scanned lists all tests that have previously run 
(and their results), and thus it's a lot larger when there are more preceding 
tests.

And if I modify things a little and make the preceding test fail, the problem 
test doesn't seem to finish at all, and uses many gigabytes of memory...

Very strange.

Pip