On Fri, 2022-10-28 at 17:20 +0200, Arthur Cohen wrote: > > > On 10/28/22 15:06, David Malcolm wrote: > > On Fri, 2022-10-28 at 13:48 +0200, Arthur Cohen wrote: > > > Hi David, > > > > > > On 10/26/22 23:15, David Malcolm wrote: > > > > On Wed, 2022-10-26 at 10:17 +0200, > > > > arthur.co...@embecosm.com wrote: > > > > > This is the fixed version of our previous patch set for gccrs > > > > > - > > > > > We've > > > > > adressed > > > > > the comments raised in our previous emails.
[...snip...] > > > > I'm guessing that almost all of gccrs testing so far has been on > > relatively small examples, so that even if the GC considers > > collecting, > > the memory usage might not have exceeded the threshold for actually > > doing the mark-and-sweep collection, and so no collection has been > > happening during your testing. > > > > In case you haven't tried yet, you might want to try adding: > > --param=ggc-min-expand=0 --param=ggc-min-heapsize=0 > > which IIRC forces the GC to actually do its mark-and-sweep > > collection > > at every potential point where it might collect. > > That's very helpful, thanks a lot. I've ran our testsuite with these > and > found no issues, but we might consider adding that to our CI setup to > make sure. Great! Though as noted, for libgccjit it slows the testsuite down *massively*, so you might want to bear that in mind. I'm doing it for libgccjit because libgccjit looks like a "frontend" to the rest of the GCC codebase, but it's a deeply weird one, and so tends to uncover weird issues :-/ Dave > > Kindly, > > Arthur > > > I use these params in libgccjit's test suite; it massively slows > > things > > down, but it makes any GC misuse crash immediately even on minimal > > test > > cases, rather than hiding problems until you have a big (and thus > > nasty) test case. > > > > Hope this is helpful > > Dave > > > > > > > > > > > Hope this is constructive > > > > Dave > > > > > > > > > > Thanks a lot for the input, > > > > > > All the best, > > > > > > Arthur > > > > > > > > > > > > > >
