Bugzilla – Full Text Bug Listing
| Summary: | JVMTI standalone profiling data collection | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Chris Elford <chris.l.elford> |
| Component: | TPTP | Assignee: | Alexander N. Alexeev <analexee> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | analexee, asaf.yaffe, ewchan, jkubasta, kiryl.kazakevich, Mikhail.Voronin, paulslau, sluiman |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| URL: | http://www.eclipse.org/tptp/groups/Architecture/documents/features/hf_196744.html | ||
| Whiteboard: | closed471 | ||
|
Description
Chris Elford
Please consider breaking this into more granular enhancement suggestions. Simplifying the command line/environment settings is one thing, beefing up documentation is another thing.... Standalone profiling configuration wizard can be add to WB, it can gather all required information in 4-5 steps (current dir for profiling, path to JRE, filters, profiling types, target application) and generate command file. Approved by the AG for TPTP 4.5 with the following comments: -Documentation sizing is too low. 3 PD is probably too high for code review and other committer work. -If a wizard is required, it should be under a separate enhancement. -What is the profiling path? -Is this a Java application? If so, why do we need a JRE path? -Can the user specify an output mode (e.g. binary or XML)? (In reply to comment #3) > -Documentation sizing is too low. 3 PD is probably too high for code review > and other committer work. Fixed > -If a wizard is required, it should be under a separate enhancement. Opened Bug 221120. This record stills only for providing commandline help in agent > -What is the profiling path? It means path which should be used as current for profiled application. But seems it doesn't make sense amd I've removed it from wizard (see fdd for Bug 221120) > -Is this a Java application? If so, why do we need a JRE path? User may want to profile application on JVM other than used for wizard execution. > -Can the user specify an output mode (e.g. binary or XML)? Yes, such option is provided for configuration (In reply to comment #4) Thanks Alexander. > > -Is this a Java application? If so, why do we need a JRE path? > User may want to profile application on JVM other than used for wizard > execution. I would assume this would be an optional parameter. > > -Can the user specify an output mode (e.g. binary or XML)? > Yes, such option is provided for configuration Again, I would assume this would be an optional parameter and default to XML as discussed on Friday. (In reply to comment #5) > (In reply to comment #4) > > Thanks Alexander. > > > > -Is this a Java application? If so, why do we need a JRE path? > > User may want to profile application on JVM other than used for wizard > > execution. > > I would assume this would be an optional parameter. > > > > -Can the user specify an output mode (e.g. binary or XML)? > > Yes, such option is provided for configuration > > Again, I would assume this would be an optional parameter and default to XML as > discussed on Friday. > Paul, what do you mean under optional parameter in context of the console wizard? (In reply to comment #6) > Paul, what do you mean under optional parameter in context of the console > wizard? Like the existing SetConfig.bat/.sh interface, the default value would be provided (e.g. the JRE used to run the wizard) and the user would only have to enter a value if they wanted something different. We should not require users to specify properties that have default value to keep things simple. Thoughts? >
> Like the existing SetConfig.bat/.sh interface, the default value would be
> provided (e.g. the JRE used to run the wizard) and the user would only have to
> enter a value if they wanted something different. We should not require users
> to specify properties that have default value to keep things simple. Thoughts?
>
I was confused mainly by phrase "as discussed on Friday" :)
Sure, one of the intention to create such wizard was to leave for user minimum required things to do, I'd call it just push the button configuration.
(In reply to comment #8) > > > > Like the existing SetConfig.bat/.sh interface, the default value would be > > provided (e.g. the JRE used to run the wizard) and the user would only have to > > enter a value if they wanted something different. We should not require users > > to specify properties that have default value to keep things simple. Thoughts? > > > I was confused mainly by phrase "as discussed on Friday" :) > Sure, one of the intention to create such wizard was to leave for user minimum > required things to do, I'd call it just push the button configuration. > Exactly what I was thinking:) couldn't this be at least partially address with out a wizard/gui? It seems a few well commented scripts that defaulted etc.. would be a good step forward, and relatively easy to get in and tested. (In reply to comment #2) > Standalone profiling configuration wizard can be add to WB, it can gather all > required information in 4-5 steps (current dir for profiling, path to JRE, > filters, profiling types, target application) and generate command file. > Profile to file support in existing driver is providing a similar user flow as mentioned above: user specify the filter and options in a GUI with an user-defined output file in the file system to store the trace events. Client reroute all trace event received to the file specified instead of loading into the model. I think to support real 'standalone', there should no be GUI involved, and I think a default filter and option files (with comment/instruction inside) is a good starting point, allowing user to under the structure and modify for his/her own needs. > Profile to file support in existing driver is providing a similar user flow as > mentioned above: user specify the filter and options in a GUI with an > user-defined output file in the file system to store the trace events. Client > reroute all trace event received to the file specified instead of loading into > the model. Such scenario hardly can substitute standalone profiling with options passed via command line. Main reason of data collection directly to file is Agent Controller and WB overhead elimination. But in mentioned approach they still involved. Also for some users would be useful just to know what arguments should be added for profiling in existed scripts than try to reproduce scripts environment in Launch configuration. > > I think to support real 'standalone', there should no be GUI involved, and I > think a default filter and option files (with comment/instruction inside) is a > good starting point, allowing user to under the structure and modify for > his/her own needs. > I agree that sample scripts could be quite useful. But just to clarify, Eugene, do you consider console configuration script as GUI? Maybe if number of parameters for profiler will increased anyway we will have to provide some helper for configuration. on scripts, where can we put them in TPTP distribution? I propose to create such scripts near libraries in org.eclipse.tptp.javaprofiler\ for RAC or [win_ia32 | linux_ia32 | ... ] for IAC (In reply to comment #12) > I agree that sample scripts could be quite useful. But just to clarify, Eugene, > do you consider console configuration script as GUI? Maybe if number of > parameters for profiler will increased anyway we will have to provide some > helper for configuration. > on scripts, where can we put them in TPTP distribution? > I propose to create such scripts near libraries in > org.eclipse.tptp.javaprofiler\ for RAC > or > [win_ia32 | linux_ia32 | ... ] for IAC > I would think these scripts should be located with the setconfig script and the RAServer etc. executables. Keeping the path simple and as short as possible seems the right thing to do. If there was a startcg script for callgraph and so on for each collection type, and a file to hold filters for each, then it seems the bulk of the typical use cases are kept simple. (In reply to comment #12) > I agree that sample scripts could be quite useful. But just to clarify, Eugene, > do you consider console configuration script as GUI? Maybe if number of > parameters for profiler will increased anyway we will have to provide some > helper for configuration. > on scripts, where can we put them in TPTP distribution? > I propose to create such scripts near libraries in > org.eclipse.tptp.javaprofiler\ for RAC > or > [win_ia32 | linux_ia32 | ... ] for IAC > Hi, I don't consider console configuration as GUI and I agree with Harm that the script is better be placed with the setConfig under the same folder (bin). That is probably what user will think of first when they try to look for executable/batch files. (In reply to comment #14) > Hi, I don't consider console configuration as GUI and I agree with Harm that > the script is better be placed with the setConfig under the same folder (bin). > That is probably what user will think of first when they try to look for > executable/batch files. > I agree, it is best place for scripts, but I had some concerns since it is AC directory. And profiler just plugin for AC which should contain all its files under one plugin directory. So if placing scripts in 'bin' directory is good for you, it is good for me either. Mass update of P1 enhancements and defects targetted to future to P2. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As such, TPTP is not delivering enhancements. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement is resolved as WONTFIX. For this enhancement to be considered, please re-open with an attached patch including the Description Document (see http://www.eclipse.org/tptp/home/documents/process/development/description_documents.html), code (see http://www.eclipse.org/tptp/home/documents/resources/TPTPDevGuide.htm), and test cases (see http://www.eclipse.org/tptp/home/documents/process/TPTP_Testing_Strategy.html). As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |