[jbosstools-dev] Question on ASTools profiling

[Rob Stryker]

On 11/07/2013 08:20 PM, Max Rydahl Andersen wrote:
> On Wed, Nov 06, 2013 at 10:43:34PM +0800, Rob Stryker wrote:
>>
>> This block of code is also a bit inconvenient since it happens after 95%
>> of the launch code but before the vmrunner.run(etc), so it requires us
>> to basically copy a superclass's entire 300 line method in order to
>> sneak the profiling bit in before the launch is run.
>
> Why do you need 300 line method to add this ?
> It's what other server adapters do too for enabling profile is it not ?
>

There are 2 platform classes here.  JavaLaunchDelegate, which we do not 
use since it depends heavily on Projects....   and its superclass, 
AbstractJavaLaunchConfigurationDelegate.

Our current launch delegate extends 
AbstractJavaLaunchConfigurationDelegate, and copies a method from 
JavaLaunchDelegate into our class. So we copy the 300 lines from what I 
would call a "sister" class (same parents).

Snjezana had originally put the profile code in right before 
runner.run.  This means we need to copy the entire 300 line method to 
squeeze our profile business in after the first 280 lines but before the 
runner.run(etc).   Launch configuration classes really don't need to 
maintain state at all. Almost all the methods have signatures that pass 
everything around, so you can actually do delegating very easily.  For 
example, I can replace the code in this method entirely with new 
JavaLaunchDelegate().launch(etc).

The problem is, we want to add in the profiling hooks right before 
launch, but after everything else, in the method.

Example:
    public void launch(etc etc) {
         code 1
         code 2
         code 3
         etc etc etc
         code 100
         // WHERE WE WANT TO PUT PROFILING HOOK
         runner.run(etc);
    }

We need to squeeze profilingCode between code100 and runner.run(etc).  
The only way to do this is to copy the entire method. At least that's my 
impression. If we were to replace with new 
JavaLaunchDelegate.launch(etc),  then the runner.run(etc) would execute 
before our profiling code.

if we instead did:
     profilingCode();
     new JavaLaunchDelegate.launch(etc);

Then we have the new values from profiling code potentially being 
overwritten by the code in JavaLaunchDelegate, which will use the values 
already set, basically.

But I'm not familiar with profiling which is why I was asking Snjezana.

> Maybe we got it in the wrong place since this actually sounds like 
> something that all server adapters should be able to benefit from as 
> long as they are launched
> with pure java.
>
>> Anyway, any advice on how this works, what kinda changes it can make to
>> the launch, or how to set up my env to test it, would be very helpful.
>
> Install a Profiler plugin, like YourKit 
> (http://www.yourkit.com/features/eclipse/) which supports
> Eclipse notion of Profile runs.
>
> Then you should be able to run a profiler against any java launch, 
> including our server adapter.
>
> /max
>