Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

alternative for #46, hybrid approach: #47

Merged
merged 10 commits into from Oct 8, 2020
Merged

alternative for #46, hybrid approach: #47

merged 10 commits into from Oct 8, 2020

Conversation

aviatesk
Copy link
Owner

@aviatesk aviatesk commented Oct 7, 2020

  • selective (partial) interpretation for "should-not-be-abstracted" statements
  • then profile on toplevel MethodInstance

eventually closes #26 , #46

- selective interpretation for non-abstract statements
- then profile on toplevel `MethodInstance`
@aviatesk aviatesk changed the title wip: alternative for #46, hybrid approach: alternative for #46, hybrid approach: Oct 8, 2020
@codecov-io
Copy link

codecov-io commented Oct 8, 2020

Codecov Report

Merging #47 into master will decrease coverage by 5.53%.
The diff coverage is 97.29%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #47      +/-   ##
==========================================
- Coverage   85.69%   80.15%   -5.54%     
==========================================
  Files           9       18       +9     
  Lines         706     1401     +695     
==========================================
+ Hits          605     1123     +518     
- Misses        101      278     +177     
Flag Coverage Δ
#unittests 80.15% <97.29%> (-5.54%) ⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/abstractinterpreterinterface.jl 86.36% <ø> (ø)
src/reports.jl 92.09% <66.66%> (-0.44%) ⬇️
src/abstractinterpretation.jl 95.79% <95.00%> (+0.03%) ⬆️
src/virtualprocess.jl 95.50% <98.70%> (+1.62%) ⬆️
src/TypeProfiler.jl 53.70% <100.00%> (+9.25%) ⬆️
D:/a/TypeProfiler.jl/TypeProfiler.jl/src/print.jl 0.00% <0.00%> (ø)
D:/a/TypeProfiler.jl/TypeProfiler.jl/src/watch.jl 4.16% <0.00%> (ø)
...:/a/TypeProfiler.jl/TypeProfiler.jl/src/tpcache.jl 92.85% <0.00%> (ø)
...r.jl/TypeProfiler.jl/src/abstractinterpretation.jl 95.79% <0.00%> (ø)
... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a60b6c6...1e331a8. Read the comment docs.

@aviatesk
Copy link
Owner Author

aviatesk commented Oct 8, 2020

okay, this is in pretty good shape, now

@aviatesk aviatesk merged commit 12dcf08 into master Oct 8, 2020
@aviatesk aviatesk deleted the avi/hybrid branch October 8, 2020 14:43

# adapted from https://github.com/JuliaDebug/JuliaInterpreter.jl/blob/2f5f80034bc287a60fe77c4e3b5a49a087e38f8b/src/interpret.jl#L188-L199
# works as `JuliaInterpreter.evaluate_call_compiled!`, but special cases for TypeProfiler.jl added
function evaluate_call_recurse!(interp::ActualInterpreter, frame::Frame, call_expr::Expr; enter_generated::Bool=false)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Today I noticed that defining this method triggers more than 500 invalidations if you've loaded Revise. (In contrast, extending step_expr! only triggered 8 invalidations, though if one gets fixed it might alter the count for the other.) We can live with that, but it might also be worth considering whether there are alternatives:

  • define some inner call in JuliaInterpreter's evaluate_call_recurse! method that obviates the need for this extension (i.e., can we add a branch that handles includes?)
  • move the definition of ConcreteInterpreter and this second method to JuliaInterpreter.jl (I suspect that is not a good solution)
  • always use runtime dispatch to call evaluate_call_recurse!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

virtualprocess.jl is problematic, find an alternative way to simulate toplevel execution
3 participants