I was getting nps>200 before, now I get nps ~40. Dropping MAXTRACE from 20000 back to 2000 helps some (nps ~160) but clearly something odd is going on. Needs investigating.
I'm seeing huge amounts of time in mark/sweep, as well as many trace buffer flushes. Investigating whether calling LCompressedBuffer.clear() after each trace is generated will let us avoid calling GC::Collect() explicitly.
Created attachment 297228 [details] [diff] [review] Bump trace cache to 16M to avoid thrashing Also - support SWITCH in trace() - free LIR buffers explicitly at end-of-trace time
Attachment #297228 - Flags: review?(stejohns) → review+
Comment on attachment 297228 [details] [diff] [review] Bump trace cache to 16M to avoid thrashing we might need to tweak pendingTrace.gen later since it holds onto the buffer. But that should be fine for now until we implement trees.
Attachment #297228 - Flags: review?(rreitmai) → review+
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Closing out all TT: transfer bugs that are resolved fixed.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.