924147 - Enable dark matter detector on engineering builds

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[Diego Wilson [:diego]]

Attachment: pr.htm

We have found this useful for debugging FxOS memory usage and would like to enable it by default on debug builds.

Comment 1

[Diego Wilson [:diego]]

I updated the PR to enable on -eng builds only as per :m1's suggestion

Comment 2

[[:fabrice] Fabrice Desré]

What's the runtime impact of enabling that?

Comment 3

[Nicholas Nethercote [inactive]]

Non-trivial:  a small amount of extra work on every allocation and deallocation, and a stack trace is obtained every once in a while.  Debug builds are so much slower than opt builds that the slowdown caused by DMD may not matter, but you'd have to measure to be sure.

Comment 4

[Michael Wu [:mwu]]

What about building DMD but not enabling?

Comment 5

[Nicholas Nethercote [inactive]]

> What about building DMD but not enabling?

Less overhead, but still non-zero.  But you're going to have to measure it to know for sure.

Comment 6

[Diego Wilson [:diego]]

Fabrice, what do you suggest to move this forward? It's not clear to me what measurements (if any) would we need. If I can do this myself I can try it out.

Comment 7

[[:fabrice] Fabrice Desré]

(In reply to Diego Wilson [:diego] from comment #6)
> Fabrice, what do you suggest to move this forward? It's not clear to me what
> measurements (if any) would we need. If I can do this myself I can try it
> out.

My fear is that any performance testing done with dmd enabled will be badly biased. Since I think that all the perf automation runs with eng builds, I'd rather not enable that by default.

Comment 8

[Nicholas Nethercote [inactive]]

All this speculation about performance is entertaining but this bug won't move forward without measurements.

Having said that, I think doing memory measurements in debug builds is a bad idea because they won't match the measurements in opt builds.  The particular case I know of is that the entry storage of pldhash tables -- of which we have many -- is larger on debug builds than opt builds, up to twice as large, due to it storing extra verification info.  And there might be other cases like this.

Comment 9

[Michael Wu [:mwu]]

This bug's summary is a bit misleading - we're considering building dmd on engineering (gonk) builds, not debug (gecko) builds. Engineering builds normally build opt versions of gecko, not debug.

Comment 10

[Diego Wilson [:diego]]

This doesn't seem to be going anywhere. Oh well.

Comment 11

[Michael Wu [:mwu]]

If it would help, we can probably enable dmd on debug (mozilla debug, not userdebug) builds on tinderbox just to make sure they don't break.

Comment 12

[Nicholas Nethercote [inactive]]

> If it would help, we can probably enable dmd on debug (mozilla debug, not
> userdebug) builds on tinderbox just to make sure they don't break.

That's probably worthwhile!

Comment 13

[Diego Wilson [:diego]]

(In reply to Michael Wu [:mwu] from comment #11)
> If it would help, we can probably enable dmd on debug (mozilla debug, not
> userdebug) builds on tinderbox just to make sure they don't break.

That would definitely help. How do we go about doing that?

Comment 14

[Nicholas Nethercote [inactive]]

It requires modifying browser/config/mozconfigs/*/debug.  Unfortunately, those builds all use --enable-trace-malloc, which is incompatible with --enable-dmd :(  And I don't think this is important enough to be worth creating additional builds.