Re: problem in spark command line options

[Ondrej Lhotak <olhotak@sable.mcgill.ca>]

On Mon, Apr 14, 2003 at 09:06:17PM -0400, Navindra Umanee wrote:
> Nikhil Mahajan <niks729@yahoo.com> wrote:
> > Hi Navin,Thanks for the reply. I did that and now it is kind of
> > working. i.e. the following command does produce a jar file:java
> > -mx100m soot.Main -a --app -p wjtp.Spark dumpHTML:true,disabled:false
> > hello However, it produces a jar file of size 27MB when the class file
> > hello just has one System.out.println statement and that is it. i
> > tried runningjava -mx100m soot.Main -a --app -p wjtp.Spark
> > disabled:false,onFlyCallGraph:true,dumpHTML:true hello and that gave
> > me a jar file of 30MB. I do not understand this behavior at all. Can
> > you please explain where i am going wrong.
> 
> Well, I tried this myself, just for fun.  As far as I can tell, the
> jar file you are talking about is pag.jar, which is itself a
> representation of the Pointer Assignment Graph in HTML.  Since this is
> a whole program analysis, the jar file is huge.
> 
> Your confusion, as far as I can tell, is that pag.jar is bigger in the
> case of onFlyCallGraph since we would expect the PAG to be smaller
> than in the conservative case.
> 
> While I couldn't reproduce that myself, I should point out that the
> size of the jar file really isn't indicative of anything other than
> what the size of the bundled and compressed HTML files amounts to.
> Try counting the number of the nodes in the graph with something like
> "jar xt pag.jar | wc -l" for a better indication!

The idea behind the dumpHTML option is to have a way to look at the PAG
for debugging purposes. Since the graph is typically huge, a graphical
representation is impractical. Instead, I generate an HTML page for each
node, with links for edges, so you can browse the graph by following
edges from node to node in a web browser. But, since this HTML
representation is quite verbose, it gets very large (typically about a
gigabyte). It's highly compressible, though, so Spark puts it all in a
big jar file, which you can unjar somewhere where you have lots of disk
space and browse.

As for the size of this file, it's hard to predict because of the
compression. I would expect the ahead-of-time call graph to produce a
bigger PAG, but with more regularity and therefore more compressible.
So, it's hard to tell which will end up being smaller when compressed.

Ondrej