Discussions
Categories
- 195.9K All Categories
- 2.1K Data
- 208 Big Data Appliance
- 1.9K Data Science
- 447.2K Databases
- 220.8K General Database Discussions
- 3.7K Java and JavaScript in the Database
- 23 Multilingual Engine
- 516 MySQL Community Space
- 463 NoSQL Database
- 7.7K Oracle Database Express Edition (XE)
- 2.9K ORDS, SODA & JSON in the Database
- 461 SQLcl
- 3.9K SQL Developer Data Modeler
- 185.8K SQL & PL/SQL
- 20.9K SQL Developer
- 292.4K Development
- 7 Developer Projects
- 121 Programming Languages
- 289.2K Development Tools
- 94 DevOps
- 3K QA/Testing
- 645.4K Java
- 22 Java Learning Subscription
- 36.9K Database Connectivity
- 150 Java Community Process
- 104 Java 25
- 22.1K Java APIs
- 137.8K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 14 Java Essentials
- 142 Java 8 Questions
- 85.9K Java Programming
- 79 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.2K Java SE
- 13.8K Java Security
- 197 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 221 LiveLabs
- 34 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.8K Other Languages
- 2.3K Chinese
- 166 Deutsche Oracle Community
- 1.2K Español
- 1.9K Japanese
- 225 Portuguese
whatis 'limited feature mode' in discover?
Hi,
I was playing with discover from Studio 12 update 4, and found the performance of instrumented binaries really slow (factor of 50 - 60 slower than uninstrumented binaries). With -l, the performance is far better, but I wonder what these 'limited features' really mean. The documentation does not expand on this. Could someone explain the tradeoff between 'normal instrumentation' and 'limited feature mode' (i.e. which checks are done/omitted in these modes)?
Regards
Dieter Ruppert
Best Answer
-
Full instrumentation means taking the binaries apart and checking (nearly) every memory operation to see if it's valid or not. So the slowdown is proportional to the number of memory operations, so some apps will be impacted more than others. With light instrumentation the tool is just checking the library calls, and not instrumenting the binary. So you can pick up some things - like memory that wasn't freed, or double free - but you cannot get anywhere near the level of detail from as from full instrumentation. You might find this blog post from Raj interesting: https://blogs.oracle.com/raj/entry/move_over_purify_and_valgrind He talks about the slowdown from instrumentation. Regards, Darryl.
Answers
-
Full instrumentation means taking the binaries apart and checking (nearly) every memory operation to see if it's valid or not. So the slowdown is proportional to the number of memory operations, so some apps will be impacted more than others. With light instrumentation the tool is just checking the library calls, and not instrumenting the binary. So you can pick up some things - like memory that wasn't freed, or double free - but you cannot get anywhere near the level of detail from as from full instrumentation. You might find this blog post from Raj interesting: https://blogs.oracle.com/raj/entry/move_over_purify_and_valgrind He talks about the slowdown from instrumentation. Regards, Darryl.
-
Hi,
thanks for the clarification. As I understand it, this 'limited feature mode' misses most of the error categories listed in the manual, in particular UMRs and ABRs. I will play with optimization, perhaps this might reduce the frequency of memory references and bring the performance impact to a more tolerable level.
Regards
Dieter Ruppert
-
If you are interested in near realtime memory error detection, then you might take a look at the ADI feature on SPARC M7. You can sign up for access here: https://swisdev.oracle.com/ And there's information on ADI here: https://swisdev.oracle.com/_files/What-Is-ADI.html Darryl.