For measuring performance of the GC it would be nice to be able to call from a script JS_SetGCParameter to change JSGC_MAX_BYTES and JSGC_MAX_MALLOC_BYTES as suitable.

The patch adds gcparam to jsshell, a wrapper for JS_SetGCParameter.

The next time I should remember that for fast natives the return value must be set in any case.

Comment on attachment 286300 [details] [diff] [review] v2 >+ fprintf(gErrFile, >+ "gcparam: argument 1 must be either " >+ "maxBytes or maxMallocBytes\n"); This should be a JS_ReportError call -- also it should imitate other such calls by not including "gcparam: " at the front. Final nit: "first argument" is better than argument 1. >+ fprintf(gErrFile, >+ "gcparam: argument 2 must be convertable to uint32 with " >+ "non-zero value\n"); Ditto. r=me with these changes. /be

Here is the patch to commit with nits addressed. I also replaced fprintf by JS_ReportError in the implementation of countHeap and dumpHeap shell functions.

I checked in the patch from comment 4 to CVS trunk: Checking in js.c; /cvsroot/mozilla/js/src/js.c,v <-- js.c new revision: 3.169; previous revision: 3.168 done

peterv backed this out on 20071028. Shouldn't we reopen it?

Bah, that's not what I meant to do. I'll reland this tomorrow.

Undid my backout and relanded this.

do you think it would be worth it to expose this to the command line js and jsDriver so we could run the test suite with specific values?

(In reply to comment #9) > do you think it would be worth it to expose this to the command line js and > jsDriver so we could run the test suite with specific values? The function is already exposed through -e option as in: js -e 'gcparam("maxBytes", 100<<10)' <other options and arguments> Theoretically it is not ideal as it executes JS code which may be affected by other options. But I suggest to worry about it when we get a test case where -e would not be enough.