After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 630908 - use JS_updateMallocCounter
use JS_updateMallocCounter
Status: RESOLVED OBSOLETE
Product: gjs
Classification: Bindings
Component: general
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gjs-maint
gjs-maint
Depends on:
Blocks:
 
 
Reported: 2010-09-29 15:02 UTC by Havoc Pennington
Modified: 2018-01-27 11:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Havoc Pennington 2010-09-29 15:02:50 UTC
we've had trouble with GdkPixbuf in particular because it may be several megabytes or more, but spidermonkey thinks it's just the object proxy's size.
This means you can generate gigabytes of pixbufs and never GC.

It looks like new spidermonkey has JS_updateMallocCounter() and I _think_ it would be correct to do something like:

 JS_updateMallocCounter(pixbuf->rowstride * pixbuf->height);

when creating a pixbuf.

How to do this generically I don't know... it almost requires an extra hook to be registered with each GType.

An alternative approach would be to install a g_malloc mem vtable that does JS_updateMallocCounter on *all* g_malloc. Probably the most sane approach, really.

I don't think updateMallocCounter has to be precise; it's never decremented again or anything. It just has to generally give spidermonkey an idea how much memory we've "gone through" lately, as I understand it.
Comment 1 GNOME Infrastructure Team 2018-01-27 11:44:55 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gjs/issues/52.