-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
caleb/fix/stringdata #417
caleb/fix/stringdata #417
Conversation
…ir data pointers have a GC occurs
} | ||
|
||
JS::AutoCheckCannotGC nogc; | ||
for (const JSStringProxy *jsStringProxy: jsStringProxies) { // char buffers may have moved, so we need to re-point our JSStringProxies |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In symmetry to this, would a Python str object move its char buffers, and how to notify the JS land?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know if python string objects move their buffers? As far as I'm aware they never move
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the above comments, the pull request looks good to me.
Good code!
Between JS_SetGCCallback and JS::AddGCNurseryCollectionCallback(), we should cover all cases where a JS String can be moved. (per jonco from moz, he hacks on the GC) |
In pursuit of fixing #340, this PR fixes some issues with string object reference counts. We now decrement strings (as well as lists and objects) even if their refcount = 1, which we were not doing before due to potential crashes during python's finalization, but now we just check if python is finalizing and if so skip all the refcount managing.
This also more intelligently manages the reference counts of string objects depended upon by JSExternalStrings, which will now have exactly the same lifetime as the JSExternalString (unless some other thing is keeping it alive, of course) without leaking memory.
Finally, it adds a GC callback that re-points all of the JSStringProxy data pointers to their associated data, since they may have moved during a GC.