377895 - XPConnect still has #ifdef GC_MARK_DEBUG

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Peter Van der Beken [:peterv]]

They should probably be removed and the code inside the ifdefs rewritten or removed (GC_MARK_DEBUG was removed from SpiderMonkey in bug 375270).

Comment 2

[Igor Bukanov]

I reopen the bug since the bug 378255 is about restoring dumping heap functionality that was available with GC_MARK_DEBUG. This is different from this bug since with bug 378261 fixed one can compile with GC_MARK_DEBUG defined and GC_MARK_DEBUG code in xpcconnect would provide better more descriptive dumps for any user of JS_DumpHeap.   

So the idea is to make the debug info available in a generic DEBUG build.

Comment 3

[Boris Zbarsky [:bzbarsky]]

So...  I think a lot of these could in fact just use DEBUG, since they just change what's passed to the JSAPI rooting methods, right?

Comment 4

[Igor Bukanov]

(In reply to comment #3)
> So...  I think a lot of these could in fact just use DEBUG, since they just
> change what's passed to the JSAPI rooting methods, right?

In principle the answer is yes, one can replace GC_MARK_DEBUG with just DEBUG, but that may result in a significant slowdown due to extra name allocations. The right solution is to replace calls to JS_AddNamedRoot/JS_LockGCThing via a custom data structure for xpconnect roots and use the API proposed in bug 340212 to integrate the data structure with tracing/marking. This should not only saves memory in an optimized build but also allow to provide tracing info in a generic DEBUG build without strdup overhead.

Comment 5

[Peter Van der Beken [:peterv]]

Can we either close this bug or change its summary? Looks like GC_MARK_DEBUG is gone.

Comment 6

[Igor Bukanov]

This is indeed fixed now as check ins for bug 340212 and bug 379220 removed all GC_MARK_DEBUG code.