Discussions
Categories
- 197K All Categories
- 2.5K Data
- 546 Big Data Appliance
- 1.9K Data Science
- 450.8K Databases
- 221.9K General Database Discussions
- 3.8K Java and JavaScript in the Database
- 31 Multilingual Engine
- 552 MySQL Community Space
- 479 NoSQL Database
- 7.9K Oracle Database Express Edition (XE)
- 3.1K ORDS, SODA & JSON in the Database
- 556 SQLcl
- 4K SQL Developer Data Modeler
- 187.2K SQL & PL/SQL
- 21.4K SQL Developer
- 296.3K Development
- 17 Developer Projects
- 139 Programming Languages
- 293K Development Tools
- 110 DevOps
- 3.1K QA/Testing
- 646.1K Java
- 28 Java Learning Subscription
- 37K Database Connectivity
- 158 Java Community Process
- 105 Java 25
- 22.1K Java APIs
- 138.2K Java Development Tools
- 165.3K Java EE (Java Enterprise Edition)
- 19 Java Essentials
- 162 Java 8 Questions
- 86K Java Programming
- 81 Java Puzzle Ball
- 65.1K New To Java
- 1.7K Training / Learning / Certification
- 13.8K Java HotSpot Virtual Machine
- 94.3K Java SE
- 13.8K Java Security
- 205 Java User Groups
- 24 JavaScript - Nashorn
- Programs
- 468 LiveLabs
- 39 Workshops
- 10.2K Software
- 6.7K Berkeley DB Family
- 3.5K JHeadstart
- 5.7K Other Languages
- 2.3K Chinese
- 175 Deutsche Oracle Community
- 1.1K Español
- 1.9K Japanese
- 233 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.