Closed Bug 1309843 Opened 8 years ago Closed 6 years ago

Duplicate compacting GC builds happening on try

Categories

(Core :: JavaScript: GC, defect, P3)

defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jonco, Unassigned)

Details

(Keywords: triage-deferred)

Compacting GC builds are always configured with --enable-debug:

https://dxr.mozilla.org/mozilla-central/source/js/src/devtools/automation/variants/compacting#2

At the moment we do CGC builds for both debug and opt configurations on Windows on try, e.g.:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=f5c6ad69203a

This is a waste if they both end up being the same build. 

It seems like we always want to --enable-optimize otherwise the tests take to long.  I guess this is why CGC builds generally appear as part of the opt build series for a platform.

On inbound, we don't seem to do SM builds on Windows or OSX at all, or at least I couldn't see any:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=d9dd5cab64b250cb706e4eb3b1cc8179bb65eb8f

That also seems worrying!

On central we don't do any SM builds on OSX, but we do have a Windows debug CGC build:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-central&revision=feb1c52ebe9ef8cff09dea275aa06d9441f5fe93

I think we should do all our CGC builds in either the debug or the opt series and be consistent.  We should also remove the CGC builds from Windows debug on try.  (Maybe we should do more SM builds on inbound too, but that's probably outside the scope of this bug).
Steve, I'm needinfoing you because I think you understand how this is set up.  Does the above make sense?
Flags: needinfo?(sphink)
Keywords: triage-deferred
Priority: -- → P3
Looking at the current configuration, I see win32-debug SM(cgc) builds and linux64-debug SM(cgc) builds, and nothing else. They are compiled with both --enable-debug and --enable-optimize. That matches what I see on treeherder for all of central, inbound, and try. That's what I would expect.

I can easily believe that in the past things were messed up. And the OSX situation is unfortunate and confusing. We run the fewest jobs there because I don't think we can run it in AWS, and you have to do them differently. I'm not entirely sure of that situation, I guess.

Anyway, I'm closing for now, but please reopen if something about the current state doesn't look right. Or if you think there's value in optimized, non-debug, compacting jobs. (Note that SM(cgc) does not run jstests, only jit-tests. Partly because jstests take too long, especially with test262, and partly because most jstests don't run long enough to do much GC stuff but I think most jit-tests do?)
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(sphink)
Resolution: --- → WORKSFORME
(In reply to Steve Fink [:sfink] [:s:] from comment #2)
Thanks for looking into this.  It does seem fine now.
You need to log in before you can comment on or make changes to this bug.