aboutsummaryrefslogtreecommitdiffhomepage
path: root/src/main/java/com/google/devtools/build/lib/query2/engine/AbstractQueryEnvironment.java
Commit message (Collapse)AuthorAge
* Rename VariableContext to the more general purpose QueryExpressionContext ↵Gravatar shreyax2018-06-12
| | | | | | and thread it through to graph traversal functions. Some other light refactorings as well. PiperOrigin-RevId: 200292556
* Automated conversion to Java 8Gravatar laurentlb2017-06-30
| | | | | | | With a few manual fixes for readability. RELNOTES: None. PiperOrigin-RevId: 160582556
* Refactor SkyQueryEnvironment to allow preprocessing or postprocessing targetsGravatar Googler2017-06-27
| | | | | | | | Refactor SkyQueryEnvironment and a few other query helpers to make it easier to work with targets. RELNOTES: None PiperOrigin-RevId: 160165398
* In the Blaze Query implementation, use Set and Map implementations backed by ↵Gravatar nharmata2017-06-22
| | | | | | | the same KeyExtractor used that the Uniquifier implementation uses. This fixes a hypothetical issue where we were previously relying on Target#equals/hashCode. RELNOTES: None PiperOrigin-RevId: 159741545
* Don't throw runtime exception on interruption - since we know the future is ↵Gravatar Googler2017-05-26
| | | | | | already done, we should leave the thread in an interrupted state and proceed. This fixes a blaze crash when a 'genquery' execution is interrupted at the right time. PiperOrigin-RevId: 157000269
* Global cleanup change.Gravatar Googler2017-03-23
| | | | | | -- PiperOrigin-RevId: 151019690 MOS_MIGRATED_REVID=151019690
* Fix inadvertent performance regression introduced by the recent rewrite of ↵Gravatar Nathan Harmata2017-03-14
| | | | | | | | | | | | | | | | | | 'blaze query'. The "streaming" callbacks used by some query functions, e.g. 'deps', make calls to QueryEnvironment#buildTransitiveClosure. For a cold blaze server, these calls do package loading via LabelVisitor (which calls into Skyframe via a top-level #evaluate call). So we'd prefer a single massive call which can make full use of blaze's loading-phase parallelism via Skyframe over a bunch of sequential small calls. For a hot blaze server, there are two problems: (1) LabelVisitor's meager up-to-date check isn't useful (as in we cannot reuse old visitations) when we do a whole bunch of small visitations instead of one massive one. (2) The actual work of the LabelVisitor (building up a portion of a temporary graph) isn't being effectively parallelized when we do it sequentially in small chunks. This issue is yet another subtle reason why the old BlazeQueryEnvironment#eval made sense (and why it was unfortunately not compatible with the streaming query evaluation model from the beginning). -- PiperOrigin-RevId: 150081619 MOS_MIGRATED_REVID=150081619
* Description redacted.Gravatar Nathan Harmata2017-03-09
| | | | | | -- PiperOrigin-RevId: 149585165 MOS_MIGRATED_REVID=149585165
* Rollback of commit 822c37816ac669e51bec3853b41849a19ec5e230.Gravatar Nathan Harmata2017-03-01
| | | | | | -- PiperOrigin-RevId: 148844518 MOS_MIGRATED_REVID=148844518
* Reimplement blaze query using an async evaluation model. Use a concurrent ↵Gravatar Nathan Harmata2017-02-28
backend for SkyQueryEnvironment's implementation in order to achieve parallelism. Advantages: -New design has no flaws that the old design had. -Code is structured so that deadlocks due to thread starvation are impossible (yup!). Disadvantages: -The meat of this change needs to all be in a single CL because every single QueryFunction and QueryExpression needs to be rewritten in the async style. Still TODO: -Fully embrace the async model in all QueryFunctions (e.g. 'rdeps', 'allpaths'). -Use concurrency in BlazeQueryEnvironment to achieve parallel evaluation for (non SkyQuery) 'blaze query' and genquery. -- PiperOrigin-RevId: 148690279 MOS_MIGRATED_REVID=148690279
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 11:51:16 +0000