This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Hi, I have been using this ultimate profiler since long now, which proves to be better than other commercial versions and also various plugins of Eclipse. But, then just last week, I was trying to profile a code and I got this Warning from Netbeans5.5, "The limit of 64k instrumented methods has been reached. <<some_more_stuff>>" and finally "To avoid this problem, consider switching to the Part of the Application profiling mode." I consider this as a defect, since its a show-stopper for my project, where we are trying to optimise the system with the use of this great tool, but then, am not able to do anything now. Can this defect be fixed or can some one help me out by letting me know, if this same error has been fixed in the latest Milestone. It would be of great help... TIA, Thanks and Regards, Prashanth Babu.
Created attachment 48917 [details] Profiler Snapshot for a warning of more than 64k Instrumented methods
We consider this to be enhancement, since in practice there is really no need to instrument such huge number of methods. We are not aware of any use-case where this is needed. I don't know which application you try to profile, but it looks like you profile entire application (not part of application). For this mode it is wise to use instrumentation filter and do not profile JDK (Javacore) classes. If you profile some kind of application server you can also filter out various libraries. This will reduce number of profiled classes and also lower the overhead generated by profiler. If you have more questions please use users@profiler.netbeans.org or feedback@profiler.netbeans.org mailing lists.
Milestone cleanup: future->next
I have a real use-case where this is a major problem. I'm developing a very large java application and am running our standard benchmark that touches more than 64K methods. I can't profile this correctly because of this limit. There are no interesting roots to me that touch fewer than 64k methods for this particular benchmark.
I know this is an old bug. There are cases when the 64k limit is too limiting. Is this limit set withing the profiler itself or is this a limit imposed by the jvm?