This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug translator/3849] Delay assigning command-line parameters until runtime

------- Additional Comments From joshua dot i dot stone at intel dot com  2007-01-23 19:32 -------
(In reply to comment #3)
> Would this not be confusing to the user?  Would you signal an error if a
> @1/$1 was used in a compile-time context (probe points) once, then the user
> tried to rerun the script with different parameters?  Or just slow it down
> (by disabling the cache)?

This should be transparent to the user -- much like any other optimization
that a compiler does.  Most internals of compilation & optimization are
confusing to general users, but that doesn't mean we don't do it.

"Slow it down" I think is the wrong view -- rather I think we are speeding it
up by taking extra advantage of the cache when possible, and in other cases it
works simply as before.  Consider this script:

  probe$1) { if (execname() == @2) printf("%d\n", pid()) }

With these arguments on different runs:

  1. 500 foo
  2. 500 bar
  3. 100 foo
  4. 100 bar

Currently, this will produce four different cached versions of the script --
slow, yes?  With this proposal, 1 & 2 would share the same cache, and 3 & 4.
The user doesn't need to do anything differently to get this new advantage.

I've been thinking about how this might be implemented, and it seems like we
can get away with simply expanding variables where necessary, and synthesizing
globals for the others.  Thus the pass-2 output for inputs 1 & 2 would be
something like:

  global $str_arg2:string
  probe { if (execname() == $str_arg2) printf("%d\n", pid()) }

I'm using '$' here just to indicate that this is a special global -- it's
really read-only, so the translator doesn't need to emit locks.  Since the
caching hash depends on the pass-2 output, the cache will only depend on the
first argument.

> What if in the future, the translator does more optimizations with probe
> handlers (constant propagation of $1/@1 variables), which would make those
> similarly uncacheable?

Constant propagation in particular can turn into copy propagation.  But you're
right, others like constant folding are in conflict with this delayed
assignment.  That's an optimization tradeoff decision we'll have to make --
whether the gains in startup time outweigh the gains in probe handler speed.

My opinion is that scripts with arguments are meant to be called often with
different arguments, and thus mitigating the startup cost would be highly

> > Well, there's no way to pass in module parameters through stap.
> That is just a SMOP and should be added there for passing through to staprun.

Yes, we should provide that option, and that would allow people to manually
recreate the benefits I'm proposing.  Add in another SMOP to define read-only
globals in the language, and you've got it all.

But then, most optimizations *could* be done manually.  What I propose is a
simple way for users to get this benefit automatically.

> What you propose is probably implementable, but it may be too complicated
> to do and to explain.

Some aspects of our implementation might be tricky, but the only impact to the
user is that they might notice some of their scripts starting faster.


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]