00:06 <headius> errors for arjdbc tests on mysql all look similar

00:06 <headius> there may not be too many changes needed to get these suites running nearly green

17:06 <JasonLunn[m]> headius: I had lunch with Josh Haberman yesterday. You may remember him from this comment thread from ~8 years ago where you were both actively discussing the tradeoffs of FFI versus extensions https://github.com/protocolbuffers/protobuf/pull/121

17:07 <JasonLunn[m]> The subject of using FFI in the Protobuf gem has came up again internally. Since I'm also about to break ground on a technical design doc for how to build JRuby support for the gRPC gem, I'd love to get your take on whether FFI might be a better solve.

17:09 <JasonLunn[m]> If I'm understanding the core concerns from the ancient thread, the reason that Protobuf team didn't elect an FFI-based solution back in 2014 was because of memory management concerns. They pointed to the fact that the performance-focused JSON gems didn't use FFI.

17:13 <JasonLunn[m]> In the years since - has FFI gotten better at the use case where the concerns were focused - processing potentially huge trees of nested structures and "doing the right thing" with memory management when (only) arbitrary parts of the tree remain referenced by Ruby?

22:33 <lopex[m]> numbers

22:34 <lopex[m]> https://josephmate.github.io/2022-04-14-max-connections/

22:36 <headius> Jason Lunn: memory management of native memory via FFI hasn't changed substantially since then and would either require manual cleanup or a reaper thread since finalizers are going away

22:36 <lopex[m]> https://malloc.se/blog/zgc-jdk18

22:36 <lopex[m]> headius: did you know about that unloading issues ?

22:36 <headius> That's certainly a valid concern in using FFI but it seems like a native C extension has to deal with manual memory management anyway

22:39 <headius> lopex: I did not, very interesting

22:40 <headius> I would be surprised if JRuby users were not affected because we generate and throw away classes quite a bit

22:40 <lopex[m]> wrt that unloading gc fight

22:40 <lopex[m]> right ?

22:40 <lopex[m]> and why so late then

22:41 <lopex[m]> the explain the issue was no so common on plain java usages

22:45 <lopex[m]> actuallly is i*cms dead now ?

22:46 <lopex[m]> what I gather is the shift is towads aglos which release memory in huge chunks to deal with fragmentation

23:31 <JasonLunn[m]> <headius> "Jason Lunn: memory management of..." <- So if we already have the existing extensions-based Gem, you wouldn't recommend adopting FFI now as a path forward?

23:55 <puritylake[m]> Hi again all, back, honestly couldn't figure out %f for so long I gave up for a while