584187 - dehydra: add multiple script support

Status: RESOLVED WONTFIX

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Ehren Metcalfe]

Attachment: patch

A couple of things:

I'm not sure we even need the postGlobalNamespace variable. I tried removing the code calling dehydra_visitDecl from dehydra_cp_pre_genericize and couldn't find a difference when running the test suite. Also the global variable |processed| might not be necessary since gcc_plugin_post_parse should only be called once per script. For now I've left these as Dehydra fields but I may be able to remove them with a little more investigation.

I've also got an issue when using this with a static_checking build. In particular the jsstack analysis eats up a tonne of time when run with other scripts on one particular file. Yesterday this tripped an assert in nanojit but with a new tm rev. i'm just seeing horrible perf with this file.

I'm still looking into this but regardless we might want to run jsstack on js/src only (leaving js/src/config/static-checking-config.mk essentially unchanged but removing jsstack from config/static-checking-config.mk).

Comment 1

[Ehren Metcalfe]

Unfortunately, this is an across the board perf lose compared to the pure js solution.

Comment 2

[(dormant account)]

Hmm, could we maybe stick these into own threads to make em wins?

Comment 3

[(dormant account)]

Sounds like the practical solution would be to add the multiplexing script to the standard dehydra distribution and keep it in js. Thanks for doing this research.

Comment 4

[Ehren Metcalfe]

Threading could be an option for a couple of the callbacks like PLUGIN_FINISH_TYPE... rather than registering multiple callbacks spawn a thread for each script. You could also combine scripts that run with a common pass position into one pass and do the same thing.

I think I agree that it's better to go with js though. After running some tests compiling a large file with 10+ scripts I'm seeing about a 50% increase in running time (an extra minute). It could take real finagling to get the C up to speed.

Anyhow, I'll move the multiplex stuff into dehydra proper.

Comment 5

[(dormant account)]

Comment on attachment 462518 [details] [diff] [review]
patch

I think we decided that going beyond js-side multiplexing is crazyness

Comment 6

[Joshua Cranmer [:jcranmer]]

Dehydra and treehydra are no longer maintained by Mozilla.