fix: memory leak

[BobbieGoede]

🔗 Linked issue

• Version 8.0.0 rc 9 throws memory leak #2612
• Huge memory leak #2034

❓ Type of change

• 📖 Documentation (updates to the documentation or readme)
• 🐞 Bug fix (a non-breaking change that fixes an issue)
• 👌 Enhancement (improving an existing functionality like performance)
• ✨ New feature (a non-breaking change that adds functionality)
• ⚠️ Breaking change (fix or feature that would cause existing functionality to change)

📚 Description

It is unlikely that this fixes all present memory leaks in the module, but this small change appears to have a measurable impact on the memory usage.

I ran the reproductions with the latest release rc.9, and took memory snapshots with chrome. First without any requests, then running siege for 10 seconds with 10 concurrent users (siege -t 10s -c 10 "http://localhost:3000/") after which I took another snapshot. After waiting for a short moment I took another snapshot in case any more memory was cleared 🤷‍♂️. Then I installed my local modified @nuxtjs/i18n and went through the same steps.

My testing isn't exactly thorough, but it was a reliable way to see the memory usage go up and stay up, it's possible memory will still increase after longer usage and uptime, it's something that takes time and patience.

Below a comparison of the snapshots before and after installing the modified package:

I also tested #2034 (comment) (or https://github.com/danielroe/i18n-memory-leak) after making this comparison image, memory usage went from ~121mb to ~33mb.

While profiling I kept seeing nuxtI18Options and baseUrl, based on thismy theory is that the nuxt context is not being disposed of correctly as it is being set on nuxtI18nOptions in the i18n.ts plugin.

For example here:

i18n/src/runtime/plugins/i18n.ts

Lines 86 to 91 in 4bf4f50

	nuxtI18nOptions.baseUrl = extendBaseUrl(nuxtI18nOptions.baseUrl, {
	differentDomains,
	nuxt: nuxtContext,
	localeCodeLoader: defaultLocale,
	normalizedLocales
	})

nuxtI18nOptions.baseUrl is being set to a function returned from extendBaseUrl, the returned function makes use of the passed nuxt context (options.nuxt), nuxtI18nOptions is not defined in the scope of the plugin so I can imagine it would be hard to know when to dispose/free the memory? Based on this assumption I instead create a new object using nuxtI18nOptions, which since it's scoped to the plugin should be easier to safely dispose/free.

I don't know enough about memory management or garbage collection in Javascript, but I have experience optimizing memory usage for mobile games in C#, to provide a background for my reasoning. If someone has good resources on this please share them so I can form more informed conclusions 😅

Update

Based on the testing I did, I changed the way the Nuxt context is used/retrieved. Instead of passing it to functions/closures and potentially causing leaks the useNuxtApp composable is used where possible.

There is still a small and slow increase in memory usage for every few 1000s of requests, will look into that as well.

📝 Checklist

• I have linked an issue or discussion.
• I have updated the documentation accordingly.

[dargmuesli]

Wow, I just found the same cause and wanted to report it! 😂 Good thing this PR was a bit quicker than me 😉 I'll try it in my project now.

[dargmuesli]

Tried and it seems to resolve the issue! ❤️

There seems to be another leak in some head / pinia related files in my project though 😅 but that's unrelated to nuxt-i18n.

[kazupon]

That's amazing work! ❤️

The causing of memory leaks is very difficult since the code must be checked.
I appreciate your efforts 🙇

I don't know enough about memory management or garbage collection in Javascript, but I have experience optimizing memory usage for mobile games in C#, to provide a background for my reasoning. If someone has good resources on this please share them so I can form more informed conclusions

As far as I know, I think you can control GC in Javascript by using WeakRef or FinalizationRegistry to get around it.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/FinalizationRegistry
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakRef

However, unlike C# and other languages, JavaScript does not currently provide a mechanism to release resources like the dispose / descructor pattern.
So, I think the only way to intentionally control memory release in JavaScript is to use those APIs.

Once again, thank you so much!

[BobbieGoede]

There seems to be another leak in some head / pinia related files in my project though 😅 but that's unrelated to nuxt-i18n.

@dargmuesli
Happy to hear it's working, thanks for testing! I do think there is a smaller memory leak related to the head tags, still need to check if it is present without @nuxtjs/i18n, it may be caused by nuxt itself.

As far as I know, I think you can control GC in Javascript by using WeakRef or FinalizationRegistry to get around it.

@kazupon
I still need to learn more about those APIs, as well as WeakSet and WeakMap, maybe it would be easier to prevent leaks with those 😅