Closed Bug 465923 Opened 17 years ago Closed 11 years ago

Huge memory footprint on V8 benchmarks

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: s.chylek, Unassigned)

References

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 Build Identifier: I have run v8 benchmarks under TraceMonkey shell and I have noticed that they have huge virtual memory peak. For comparison I have also run v8 shell: http://code.google.com/apis/v8/raytrace.js (TM 114MB / V8 14MB) http://code.google.com/apis/v8/earley-boyer.js (TM 96MB / V8 17MB) http://code.google.com/apis/v8/deltablue.js (TM 42MB / 14MB) I measured this by examining /proc/[PID]/status file. Reproducible: Always
Version: unspecified → Trunk
Severity: enhancement → normal
Summary: Huge memory footprint on V8 benchmarks → TM: Huge memory footprint on V8 benchmarks
the shell doesn't run the GC by default.
Ok, I have run the tests with GCZeal 1 and the peak for raytrace.js is less than 6MB. However the execution time has changed from 3.44 sec to over 120 sec, so the choice is just between extremes.
GCZeal is a debugging tool. Its not meant for anything but debugging the GC and rooting. Did you try measuring the memory footprint in the browser?
No, I'm focusing on the standalone shell right now. I suppose, that in the browser the GC would be triggered (and collect a lot of garbage if GCZeal can keep the memory peak under 6MB). But for the shell the problem remains, in case of limited resources it can be crucial.
Without -j, using -b <very-large-int-constant> would call JS_MaybeGC ever 16K backward branches and returns. See also bug 465028. Cc'ing Igor. Making the shell more realistic has to be a goal at this point, given how it's used at alioth.debian.org among other places. /be
Status: UNCONFIRMED → NEW
Ever confirmed: true
When I run the v8 benchmark suite, I still see way higher memory usage with the js shell vs. the d8 shell. Not sure how valid the comparison is, though.
Summary: TM: Huge memory footprint on V8 benchmarks → Huge memory footprint on V8 benchmarks
Worth re-measuring once the new GC lands.
Depends on: GenerationalGC
Assignee: general → nobody
js: 437008 maxresident k d8: 660896 maxresident k
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.