[Swift-devel] Overview of coaster block-allocation-version issues

[Mihael Hategan]

On Fri, 2009-06-19 at 08:35 -0500, Mihael Hategan wrote:
> On Fri, 2009-06-19 at 08:31 -0500, Michael Wilde wrote:
> > 
> > On 6/19/09 8:23 AM, Mihael Hategan wrote:
> > > On Fri, 2009-06-19 at 07:47 -0500, Michael Wilde wrote:
> > >> More thoughts on this:
> > >>
> > >> (2) is a showstopper on Ranger (and possible elsewhere) and hence a much 
> > >> more important issue than (1).
> > >>
> > >> It seems like this problem merits a 2-pronged attack:
> > >>
> > >> a) reduce the overhead. Is it logging, or intrinsic to the protocol?
> > >>    -- is it obvious from the log whats causing the high overhead?
> > >>    -- its it a situation where the overhead is incurred even when
> > >>       jobs are not running, just queued?
> > > 
> > > Some profiling needs to be done.
> > 
> > Zhao or Allan, can you reproduce the problem on TeraPort or UC Teragrid, 
> > using a simple script and dummy app so that Mihael can readily reproduce?
> > 
> > Mihael, do you want them to run with profiling and post results?
> 
> That would be great. Get a hprof dump with cpu tracing enabled. See
> http://java.sun.com/developer/technicalArticles/Programming/HPROF.html

Bootstrap.java will also need to be modified for the relevant profiling
parameters to be passed to the coaster service JVM.

addDebuggingOptions() may be the right place to do so.