Community
Participate
Working Groups
While investigating https://issues.jboss.org/browse/JBIDE-21857 I found out that classes which are effectively garbage, but not collected yet in the VM are still being replaced by the JavaHotCodeReplaceManger. I have tried to come up with a patch that would allow to detect garbge classes and not do HCR with them. However, I have failed so far. I am filing this bug in the hope that you guys are smarter than me and come up with a way.
To be a bit more clear here, a loaded class (ex: servlet) in an application server may have several references to it. A user may execute some action (such as a full publish of a web app) which causes the server to remove all references to the old class, and load a new version. If a breakpoint is set in that class before the full publish action is initiated by the user, however, the old version of the class may never reach a state of having 0 references. The breakpoint itself will force a reference to the class unless the breakpoint is first disabled before the full publish action. This means a garbage collection event may never clean up the old version of the class. Subsequent small non-breaking changes to the class (such as changing a string inside a method) will create a third version. HCR will attempt to replace all versions of the class that are still active with this new third version. Since the 2nd version of the class is actively used by the application server, it will be (successfully) replaced by the non-breaking change. However, the first version, which may have differed in class structure, and was never cleaned up / garbage collected because the breakpoint prevented it from being so, will also attempt to be replaced, and this will cause another HCR failure. So I guess the usecase can be summarized as "Do not attempt to hot-code replace a class when that class has no references to it other than a breakpoint, and a newer version of the class exists in the application."
The debugger could not install breakpoints in classes that are not reacheable. Again, this comes down to the question what the "live" classes are.
To clear: "the debugger could refrain from installing..."
(In reply to Thomas Mäder from comment #3) > To clear: "the debugger could refrain from installing..." You mean, debugger could refrain from installing breakpoints if it is not reachable ? Generally breakpoints are installed before it becomes unreachable as Rob has also mentioned.
1) Yes that's what I mean. 2) The debugger could remove/reinstall breakpoints on replaced classes. That's actually the workaround I have implemented.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Anyone willing to work on this ?
