Community
Participate
Working Groups
Created attachment 173521 [details] initial extension plugin In a heap dump that has jruby executions will be thery nice if some additional informations is fetched, like ruby scripts that call java and what exactly java method is called within the jruby, since it is masked by JRuby objects. Here is simple initial plugin for these types of resolutions.
Created attachment 176780 [details] jruby stackrace reading is added. I have extended the focus of the tool, now the tool will also fetch Ruby stack traces from the heap dump. This will help a lot to ruby developers, since extracting ruby script data is not trivial. * Now with MAT you can acquire the heap dump and check the stack traces in the Ruby code. * You will get as well as leak suspect that includes ruby information and ruby stack traces. Additionally in order to get the backtraces the Ruby runtime is required. Version 1.5.1 is used, but it is compatible (tested) with heap dumps made with JRuby 1.3+
Clarification: Currently the jruby.jar should be in the root of the project in order to work.
Thanks for the suggested extension and the provided patch. I think it will be indeed interesting to a lot of people having to debug memory problems in applications running together java and jruby. I would like to include this into MAT. There are two things to consider: 1) as this is a significant amount of coding, I would file a CQ for it 2) the code requires some classes from jruby while extracting the stacktraces. I think it is not acceptable to always require jruby in order to run MAT. Still the majority of the cases will not depend on this functionality. Therefore the proposed extensions should remain as a separate bundle, and we can pack it in a separate optional feature. I will have to request the usage of jruby, so this will be a second CQ. What I still wonder is whether a) to request that jruby can be included or b) it will be sufficient to require only a "works with" dependency in order to compile against jruby, and then ask the user to install the needed bundle separately. Comments from the others on CC are welcome!
I vote for option a) to request that jruby can be included I don't see a problem to include the jruby.jar in Eclipse Orbit and consume it in that optional JRuby MAT feature. This will be easier from user point of view.
Fine. I'll create the necessary CQs and keep the bug updated.
A short update: I created CQ 4420 for the code contribution. After some discussions (in the ipzilla) it turned out that the CQ is not needed and was withdrawn. I also created CQ 4427 for the dependency on JRuby. I'll keep the message updated if there are some news.
Created attachment 178383 [details] jruby conribution v2 This version of the contribution replaces the initial version by Dimitar. What's new: - The dependencies to the org.jruby packages are now optional. - There is a wizard implemented, where the user can browse the file system for the jruby.jar. The wizard will install the jar as a bundle in the Memory Analyzer. Once this is done all functionality of the JRuby resolver will be available. - There is preference page implemented where users can check the version of currently installed JRuby bundle and eventually choose to either uninstall it, or replace it with another version. - There is a check at startup, which checks if there is a JRuby bundle already installed. If not, then the install wizard automatically pops up. There is a preference option to disable this check. - There are two plugins: one for the JRuby Resolver, and another - for the UI and operations that install/uninstall the JRuby bundle. - There is a feature implemented and ready to be included in an update site. - All strings are externalized. - Legal files and copyright headers are included. Note that there should be no dependency between the two JRuby plugins. The main plugin installs the org.jruby bundle and then refreshes the JRuby Resolver plugin. If there is a dependency, then the main plugin will be also refreshed. This way the main plugin will miss important events, fired by the OSGi framework, and will cause the installation operation to not function correctly.
Created attachment 178385 [details] patch for preference pages filter The RCP version of the Memory Analyzer filters the preference pages that are visible to users. The following patch needs to be applied in order to allow the new JRuby preference page to be visible.
CQ 4427 is approved. Krum, please proceed with submitting the code to the source code repository.
I have committed the two patches from comments 8 and 9. I made only one small modification - removed the icon which was included there. Now the source is in, however it won't compile directly checkout - one needs to manually install the jruby bundle. I also won't compile by our hudson jobs. These are open topics we have to work on.
Created attachment 182981 [details] Remove dependency on jruby I have modified the coding to remove the dependency on the jruby runtime. Now all information relevant for the stack-traces is extracted from the objects in the heap, and are no proxy objects created and passed to jruby. This should simplify a lot: - the build of this extension - the installation of the extension (i.e. the additional plugin taking care of the jruby presence is now obsolete). - no need for works-with CQ The patch only contains the changes to the resolver plugin, as I mentioned the other plugin is not needed any longer. Please have a look and doublecheck if you still get the required functionality. My tests so far bring the same results as with the originally proposed solution. If you find this ok, I will commit the patch and we can further improve it afterwards.
Created attachment 182982 [details] mylyn/context/zip
It looks ok. I do not see any difference with the heaps I already have.
I submitted the changes in SVN - just the changes to the o.e.m.jruby.resolver. In the next days I'll take care to remove the now obsolete separate bundle and to include the o.e.m.jruby.resolver in the standard mat feature.
Yesterday I removed the org.eclipse.mat.jruby.feature and org.eclipse.mat.jruby plugin. So, what is left is the org.eclipse.mat.jruby.resolver plugin. I added it to the org.eclipse.mat.feature, which means it will be available in the standard MAT, and not as an optional feature. It will be part of our contribution to Indigo M4. I added also the necessary pom.xml files for the tycho build. I think now I can close this message. Further improvements we should track in separate messages. As there is no dependency any longer on jruby, I will cancel the CQ for works-with dependency on jruby. Thanks for the contribution (and be sure to make some more :-) )
Comment on attachment 173521 [details] initial extension plugin Dimitar was the initial author, therefore I set the +iplog, although the attachment is marked as obsolete
Comment on attachment 176780 [details] jruby stackrace reading is added. Dimitar was the initial author, therefore I set the +iplog, although the attachment is marked as obsolete
