> It sounds like you're not only doing static analysis, but furthermore
> you're doing it at the bytecode level, and further, you're doing it
> by re-writing the said class files and overwriting the originals (as
> opposed to class-loading time etc). Correct?
Yes, all correct. We instrument the DaCapo benchmarks on a binary
level and then measure the instrumentation overhead.
> > Could you please confirm whether this is really currently the case
> I won't be able to do that immediately unfortunately as I'm swamped
> with reviewing duties at this moment. It should not be too hard to
> check, though, if you have the sources at hand.
That's ok, I can investigate by myself. I just thought you might
already be aware of this.
> > and
> > if so, would it be possible to change the benchmark so that it reads
> > some other class file?
> This should be easy enough to do. However, we have made it clear
> that we will NOT change the workload between major releases of the
> suite. The obvious choice in this case is to have the said classes
> in a separate jar, or similar. The scenario of overwriting source
> class files only affects those who use the source or xdeps releases.
> It should not be too hard to engineer a work around for you.
Agreed. Yet, I would propose to have that changed for the next major
> > (this class file should optimally not be part
> > of any benchmark or if it is, it should only be a library class at
> > least.
> Not sure what you're getting at here. I'm not sure why it
> particularly matters what the origins of the input classes are. The
> only issue, as far as I can tell, is trying to avoid users
> inadvertently modifying the input set. This is an engineering
> question and somewhat independent of the origins or nature of said
Yes, I agree. One basically has to make sure that the input does not
change. As long as bloat is processing itself, this may sometimes be
hard to achieve. So there should at least be a way of having it
process another (unmodified) copy of itself. Maybe it suffices to
change some build/configuration scripts. I'll look into it and let you
Sable Research Group
McGill University, Montr=E9al, Canada