Greetings, team:
This Wednesday (04.20.2005) at noon in POST 307, we will be reviewing C++ code from the module hpcs (on CVS).
1) pbb/truss/src/3D/sequential 2) pbb/truss/src/3D/parallel
Please make sure you install the latest version of Jupiter and Jupiter sensor. Otherwise you might not send the correct data to the server. ----------------------------------
To perform this review: 1) Install and/or update (a) the Eclipse Jupiter plug-in and (b) The Hackystat Jupiter sensor. 2) Checkout/Update the hpcs module from CVS. 3) Select "Review3DTruss" as the ReviewID. ----------------------------------
Please focus your attention on: pbb/truss/src/3D/sequential/TrussPbbDriver.cc pbb/truss/src/3D/parallel/TrussPbbDriver.cc any other classes you have time to review (about 6 in total)
Background Information: Please try to invoke the actual "Review Comparison" and "Review ID Analysis" in the Review category of the Analyses in public Hackystat.
Also, documentation for the Truss code can be found here (including CppDocs):
http://csdl.ics.hawaii.edu/Research/Truss
----------------------------------
Here are some questions to consider:
1) Memory Leak Problem:
C++ unfortunately does not have the level of garbage collection provided by Java. In order to prevent memory leaks, a developer must be careful to release all memory allocated in a C++ program after it has finished being used. This is especially important with heap allocation using a pointer declaration (*) followed by a "new" invocation.
For example:
Edge* connection = new Edge(0, 1, 2);
To deallocate memory for this Edge after it is done being used, a developer calls the delete mechanism.
For example:
delete connection;
In the Truss code, I have a feeling that dynamically allocated heap space is not being reclaimed as early as possible and am concerned about memory leaks (heap space not being reclaimed at all!).
In a short-lived application, a program can sometimes execute normally without the leaks being noticed. However, in a long-lived, parallel environment, even the smallest memory leaks have disasterous impacts on the execution.
If you can find places where memory is allocated and then not returned, or identify places where it can be reclaimed earlier, I would greatly appreciate it.
Thank you for reviewing the code!
Mike ------------------------------------------------------------- Supplemental Links and Resources:
The Hackystat Code Review Guidelines: * http://hackydev.ics.hawaii.edu/hackyDevSite/doc/Review.html
The Elements of Hacky Style: * http://hackydev.ics.hawaii.edu/hackyDevSite/doc/EHS.html
Jupiter Code Review Tool documentation: * http://csdl.ics.hawaii.edu/Tools/Jupiter/Core/doc/UsersGuide.html
Hackystat Jupiter Sensor documentation: * http://hackystat.ics.hawaii.edu/hackystat/docbook/apas15.html
