Community
Participate
Working Groups
For contention analysis and CP construction some changes in model is required - Adding loaders and containers for new Events - Add computation of monitors ownership transfer
Note, if this enhancement is a work item of 200320, it should be marked as a defect. Otherwise (e.g. new function not covered by 200320), you will have to request AG and PMC/PG approval to include them in 4.5.
(In reply to comment #1) > Note, if this enhancement is a work item of 200320, it should be marked as a > defect. Otherwise (e.g. new function not covered by 200320), you will have to > request AG and PMC/PG approval to include them in 4.5. > This was originally opened as an enhancement.
FDD updated, please review
Created attachment 91417 [details] Proposed model in trace.ecore Harm, could you take a look on proposed model. It is comply with FDD for Bug 200320. If it is generally Ok with you we can arrange model regeneration and commit it in CVS. It is required of further progress on enhancement. Thanks, Alex.
Created attachment 91567 [details] Loaders for new trace XML messages
Created attachment 91568 [details] updated model
Created attachment 91572 [details] Loaders for new trace XML messages Copyright notices added
(In reply to comment #4) > Created an attachment (id=91417) [details] > Proposed model in trace.ecore > > Harm, could you take a look on proposed model. It is comply with FDD for Bug > 200320. > If it is generally Ok with you we can arrange model regeneration and commit it > in CVS. > It is required of further progress on enhancement. > > Thanks, > Alex. > Sorry for the delays. Yes, let's get these changes in. I would like Eugene to be in the loop and begin review the changes as they go in as well. (model and loaders) My delay was due to our general intent to get back to having the model source actually be in a UML model until we have an alternative way to create the ecore files. But this can not hold up progress. One design point I was struggling with was the approach of just adding "events" to the model rather than resolving them at event load time into more direct data. For example having a thread object that has creation and start/stop times we have, and complimenting it with histories/lists of times certain things happened seems a bit smaller to store than a sequential list of the more or less raw events from the agent. However it seems the model was already partially down this path and you simply followed the pattern that was already there... My reaosn for worrying about this was A) concern about the size impact on the model B) because the other views we have in the profiler can not exploit this data. For example the trace based thread interaction UML view should be able to render most of the thread interaction information, but we are not populating that part of the trace model with the events. I think we need to look at this more going forward because in the end our users will get confused. I can already hear the question of why the "thread interaction" diagram is not available for thread analysis.
sorry , I added the comments and did nto check the vote button
(In reply to comment #9) > sorry , I added the comments and did nto check the vote button > Thank you Harm. So if you don't mind tomorrow I will regenerate whole model and commit it in CVS with new loaders. Thanks, Alex.
(In reply to comment #10) > (In reply to comment #9) > > sorry , I added the comments and did nto check the vote button > > > Thank you Harm. > So if you don't mind tomorrow I will regenerate whole model and commit it in > CVS with new loaders. > > Thanks, > Alex. > go for it, but as recommended in the document Alex wrote, be sure to compare closely ;-) and use the level correct level of EMF to do the gen.
Model regenerated and committed to the HEAD with loaders
tested in dev build
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.
