Repository navigation
RFC: Remove Ryan's Freelist feature #569
Description
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?
Activity
bnoordhuis commentedon Jan 23, 2015
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 commentedon Jan 23, 2015
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
wrap1 _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.1 They're NOP'ing the method, so it's actually just a mock.
vkurchatkin commentedon Jan 23, 2015
we need truly private internal modules for these kind of things.
19h commentedon Jan 23, 2015
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 commentedon Jan 25, 2015
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 commentedon Jan 25, 2015
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 commentedon Feb 4, 2015
freelistgets the same passsysdoes – it costs nothing (or next to nothing) to maintain, but could break downstream users if we remove it outright. I'd be alright with:freelist.jsto_freelist.js._http_common.jsrequire_freelist.js.freelist.jsis required.sysandfreelist.seishun commentedon Feb 14, 2015
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 commentedon Mar 24, 2015
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 commentedon Apr 29, 2015
@chrisdickinson can you run this against your static npm analyzer thing?
Trott commentedon Jul 14, 2015
There is now a micro-optimization PR on
FreeList.If (as @petkaantonov suggests),
FreeListmay be hurting performance and not helping, a benchmark showing that would be useful...mikeal commentedon Jul 14, 2015
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
syssince it probably has similar outstanding usage.thefourtheye commentedon Jul 14, 2015
@mikeal
sysandsmallocalready issue deprecation warning.1 remaining item
lib: issuing deprecation warning for freelist
trevnorris commentedon Jul 14, 2015
@mikeal The act of adding deprecation warnings, in node, is no indication that the feature will ever be removed.
mikeal commentedon Jul 14, 2015
@trevnorris i know, but we've been talking about a deprecation process that would actually remove public API at some point and printing a warning is part of that.
trevnorris commentedon Jul 14, 2015
At thanks. Missed that context skimming over the issue.
lib,test: add freelist deprecation and test
cjihrig commentedon Nov 9, 2015
It looks like this was deprecated back in io.js. Is there more to be done here? Are we actually going to remove freelist, or can this issue by closed?
mikeal commentedon Nov 9, 2015
Looks like we have a deprecation warning now, would be cool if we could close this and have it automatically re-open in a year to consider removing ;)
cjihrig commentedon Nov 9, 2015
I'm going to close. @geek would you mind being our watchdog ;-)
geek commentedon Nov 9, 2015
thefourtheye commentedon Nov 9, 2015
@mikeal Should the changes to be landed in the next major wait for an year? There are chances that we may miss them, right? Why don't we create a branch, say
v6.x, and target the PRs at it?@geek Lo 😆
Fishrock123 commentedon Nov 9, 2015
Land it in
masterand it'l make it into v6.thefourtheye commentedon Nov 9, 2015
Ah, that is why we have
semver-majortag. I should probably be sleeping at nights... Sigh..lib,test: remove publicly exposed freelist