RFC: Remove Ryan's Freelist feature

[19h]

Ho,

Ryan introduced FreeList in 2010 (landed in aadce8e) and is has been usable ever since.

However, it is not documented nor is it used in core-libraries and IMHO the code doesn't qualify for a core-module.

var fl = new (require("freelist").FreeList) ("foo", 10, function nop(){});
fl.free(123);
fl.alloc();

Comments?

[bnoordhuis]

lib/_http_common.js uses it for caching parser objects. I'd be okay with moving lib/freelist.js into lib/_http_common.js if we knew for sure that no one was using it but GH search suggests that there are at least a few projects that do.

[19h]

I'd go with moving it. I looked at each case for the first 10 pages of results and most uses of the module are either 1) node wrappers that wrap¹ _mock_ freelist for .. I guess the sake of it, 2) code by substack.. and this is the best part: substack/node-browserify/1223984 he's actually written an override for freelist, so it's not our freelist.

¹ They're NOP'ing the method, so it's actually just a mock.

[vkurchatkin]

we need truly private internal modules for these kind of things.

[19h]

On the first 20 pages, I found one actual use of the module: zxcabs/node-proxy-cache/bf3a1a4.

We could move FreeList to http#FreeList and document it, then deprecate _freelist_ as a module and warn the user to move on to http#FreeList.

[tellnes]

If it were up to me I would put it on npm, deprecated it and removed it in a major version update at a later date.

[19h]

Did this, done that: npm/freelist. Deprecation isn't that easy though, because #http requires it and we cannot simply move it there because it's a pain in the ass to move cross-require http from iojs#freelist just to have it. I'm not sure about this.. the last resort would be to simply document that feature for the time being..

[chrisdickinson]

freelist gets the same pass sys does – it costs nothing (or next to nothing) to maintain, but could break downstream users if we remove it outright. I'd be alright with:

• Copy the existing freelist.js to _freelist.js.
• Make _http_common.js require _freelist.js.
• Issue a deprecation notice if freelist.js is required.
• The next time a major version is on the table, we may consider revisit ripping out sys and freelist.

[seishun]

Was freelist ever documented? Backwards compatibility is great but we should draw the line somewhere. We shouldn't have to perpetually support an internal feature just because someone decided to use it.

[petkaantonov]

lib/_http_common.js uses it for caching parser objects. I'd be okay with moving lib/freelist.js into lib/_http_common.js if we knew for sure that no one was using it but GH search suggests that there are at least a few projects that do.

Pretty sure it could be doing more harm than good so we should re-consider even using it, v8 gc has changed a lot in the last 5 years

[Fishrock123]

@chrisdickinson can you run this against your static npm analyzer thing?

[Trott]

There is now a micro-optimization PR on FreeList.

If (as @petkaantonov suggests), FreeList may be hurting performance and not helping, a benchmark showing that would be useful...

[mikeal]

Being that this is exposed publicly we should work it through the deprecation process (which I believe @chrisdickinson is in the process of documenting and testing). This may be a good candidate to do alongside the deprecation of sys since it probably has similar outstanding usage.

[thefourtheye]

@mikeal sys and smalloc already issue deprecation warning.