634583 - Add support to the Make system for regenerating exact-gc tracer code when dependencies change

Status: RESOLVED DUPLICATE of bug 632857

(Tamarin Graveyard :: Build Config, defect)

Description

[Brent Baker]

We should add support to the make system for the exact-gc tracer code generation, similar to how the builtin code is regenerated if needed. Would need to call ./generate.py if a dependent file was modified. This requires and environment variable AVM to be set to a working avmshell.

Possible issues are:
- How large is the dependency list for the exact-gc tracer files?
- In order to run the tracer generation you need to have a working vm shell.

Comment 1

[Lars T Hansen]

The dependency set is quite large and hard to characterize.  You should probably run the script unconditionally - it's fast and can be faster, and it should not update the output file if the output has not changed (I believe it does that already).

Comment 2

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to comment #1)
> The dependency set is quite large and hard to characterize.  You should
> probably run the script unconditionally - it's fast and can be faster, and it
> should not update the output file if the output has not changed (I believe it
> does that already).

I can confirm that the scripts are fast; they take much less time to run than the *.thing.pp generators (calcdepends.py) in xplat, and about the same time as make itself takes on a run where it does nothing.

Observe (below is taken from my MacBook Pro):

Here's a run where the regeneration of the *.thing.pp files is forced, followed by a generate.py run.  The calcdepends.py run takes over 2/3's of the time.
 
tamarin-redux/objdir-rel32 (hg:default) % time ( rm *.thing.pp ; time make > /dev/null 2>&1 ; time ../generate.py > /dev/null )

real	0m0.546s
user	0m0.399s
sys	0m0.131s

real	0m0.227s
user	0m0.159s
sys	0m0.038s

real	0m0.776s
user	0m0.559s
sys	0m0.172s


Here's a run where literally make does nothing, followed by a generate.py call.  So if we unconditionally ran generate.py, we would double the trivially small amount of time for the run.  I can live with that.

tamarin-redux/objdir-rel32 (hg:default) % time ( time make > /dev/null 2>&1 ; time ../generate.py > /dev/null )

real	0m0.281s
user	0m0.205s
sys	0m0.068s

real	0m0.234s
user	0m0.162s
sys	0m0.039s

real	0m0.515s
user	0m0.367s
sys	0m0.107s


If we do run the script unconditionally (which seems reasonable to me for now), then I'll lobby to have it not spit its output to the screen about where its generating to, except for when it actually does update the file.  (Currently it unconditionally informs the invoker about what its planning to do, regardless of whether it needed to update files in the end.  That's part of why I piped to /dev/null above.)

Comment 3

[Lars T Hansen]

OK then :-)

Comment 4

[Steven Johnson]

...if we are likely to switch build systems to gyp soon, is it worth messing with the old build system to do this?

Comment 5

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to comment #4)
> ...if we are likely to switch build systems to gyp soon, is it worth messing
> with the old build system to do this?

Probably not.  This is part of the reason I have not been recently pushing on this bug or Bug 632086.

Comment 6

[Felix S. Klock II [:pnkfelix, :fklock]]

(In reply to Lars T Hansen from comment #1)
> The dependency set is quite large and hard to characterize.  You should
> probably run the script unconditionally - it's fast and can be faster, and
> it should not update the output file if the output has not changed (I
> believe it does that already).

Filing a dupe of Bug 632857; as far as I can tell, it suffices to run the xplat generation unconditionally (that's the tack Bug 632857 takes), and besides, since running it unconditionally is the strategy for the player code base, it makes some sense to use a matching strategy in AVM (to provide incentive for keeping the tracer generation fast).