Bugzilla – Full Text Bug Listing
| Summary: | Forcing garbage collection through the workbench doesn't seem to have any affect | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega |
| Component: | TPTP | Assignee: | Samson Wai <samwai> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | critical | ||
| Priority: | P1 | CC: | jkubasta, kendricw, nmehrega, yymadrian |
| Version: | unspecified | Keywords: | plan |
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | closed460 | ||
The problem is related to the fact that the piAgent is requesting a JVMPI_EVENT_HEAP_DUMP rather than triggering the RunGC interface function. This appears to have been done because of the restriction that RunGC cannot be called with GC disabled (presumably giving rise to a deadlock concern). This is not a regression. It has been this way from the beginning (ie: years). It may require careful consideration to avoid deadlock. There is some evidence this was a particular concern in the original design. I am targetting for further investigation/design in 4.2i3 (may or may not conclude with a safe solution). We need to add automated test cases for this defect. Further investigation has confirmed that the RunGC jvmpi interface function must not be run with GC disabled and that the piAgent explicitly disables GC in several places. This indeed raises a deadlock concern. The correct solution is to add a "GC" mutex to piAgent and serialize on it before disabling GC or invoking RunGC (and release it once GC is re-enabled or RuunGC returns). Some further investigation also remains to be done to ensure 1) there are no "implicit" gc disablements connected with any other user/piAgent operations. This cannot be safely implemented/completed and adequately tested across platforms in the remaining schedule for 4.2i3. As previously mentioned, this is not a regression. It has always been this way. Given the JVM spec on GC in general (it undertakes to expend effort in reclaiming storage but gives no guarantees), this is a benign error: you don't get what you want sometimes but you get as much as was guaranteed. All factors being considered (especially risk vs benefit), and with agreement of Ali and Sri, this is being deferred to 4.3 with sev=Major and priority=P2. We will add a release note to describe this limitation for 4.2. An automated test case has been created for this defect. Note that this defect makes memory leak detection with TPTP impossible. To detect memory leaks, the user usually performs a set of tasks, forces garbage collection, and expects a set of objects to be collected. If those objects are not collected, it could indicate a memory leak. Since the user has no way to force garbage collection, they'll never be able to tell whether their objects should have been collected or not. Thus making memory leak detection extremely difficult if not impossible. Further investigation has revealed that earlier jdks forced a complete GC prior to delivering a heap dump. JDKs stopped doing this at some point (possibly after JDK1.3) and this would've been when this button stopped working. Besides possible fear of deadlock, one of the reasons for the original design (ie: to request a heap dump instead of driving the RunGC interface function) was that, at least in the jdks at that time, the heap dump request unconditionally forced a GC whereas the RunGC did not always do so. This behavior of RunGC was apparently consistent with the java.lang.Runtime.gc behavior which was for the JVM to only treat such a GC request as a "suggestion" to run GC and not for the JVM to guarantee that one would be run. It is clear that the remedy is to convert to invoking the RunGC JVMPI interface function in response to this button as per comment #1. Besides ensuring against deadlock, it must alos be determined whether the usual jdks at present always force GC in response to RunGC or not (and to document the button's behavior accordingly). There has been another complaint about this defect on the newsgroup. I'm going to raise the severity to critical. This defect causes a major loss of functionality and there is no workaround for it. I think it requires immediate attention. If this defect is not going to be fixed, I suggest removing the button altogether. As the reporter I agree with Navid's comment and the severity. Not containable in 4.3 and retargetting to 4.4 as per last week's Platform call (which declined to pre-approve it). Set priority to P1 for 4.4 plan closure. No plan to fix 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. |
Driver: TPTP-4.2.0-200603291001 JVM: Sun 1.4.2_10 Consider the following class: public static void main(String[] args) throws IOException { System.out.println("Creating 100 unreferenced objects"); for (int i = 0; i < 100; i++) new GCTester(); System.gc(); System.out.println("Press enter to exit"); new BufferedReader(new InputStreamReader(System.in)).readLine(); } If this class is profiled using the "Basic Memory Analysis" type with the option "Collect instance level information" set, the memory stats view will indicate that 100 objects are collected. If the line System.gc(); is commented and garbage collection is forced via the profiling monitor view option, no objects are reported as being collected.