From shurailine at openjdk.java.net Wed Mar 10 20:01:17 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 10 Mar 2021 20:01:17 GMT Subject: RFR: Instrumentation plugin concept Message-ID: These changes are introducing a concept of an instrumentation plugin into JCov. Instrumentation plugin (defined by _com.sun.tdk.jcov.instrument.InstrumentationPlugin_) represents a logic which specifies what code instrumentation is to be performed by JCov. In the current implementation, the concept is only used to define instrumentation **additional** to that which is already done by JCov. The instrumentation performed by such plugins may or may not be relates to the instrumentation already performed by JCov. As such, JCov could be used as only an engine to load and save the code, with the additional instrumentation having nothing to do with code coverage. It is also possible to reuse the same concept **within JCov itself**. Depending on the command line option, JCov already inserts very different instrumentations. This is now controlled programmatically such as in _com.sun.tdk.jcov.instrument.DeferringMethodClassAdapter.visitMethod(int, String, String, String, String[])_ method. Such code could possibly benefit from some delegation. This actual suggested change does not suggest any changes related to code instrumentation currently supported by JCov. In addition to the instrumentation plugin, the changes suggest a way to specify a logic to save all data collected during the runtime. That is done by reusing _com.sun.tdk.jcov.runtime.JCovSaver_ interface. To better understand the concept perhaps it is helpful to take a look on the test which is suggested as a part of this change: _com.sun.tdk.jcov.instrument.plugin.FieldsTest_ and the accompanying files. The same concept is explained in more details in this draft JEP proposal: https://bugs.openjdk.java.net/browse/JDK-8043291 More work needed. Current state of the code is offered solely for the purpose of discussing the concepts of instrumentation plugin. When the concept is generally accepted, more changes to the source are needed and more testing is needed also. These are only some of the things which needs to be looked into: 1. a mechanism is required to notify the plugin about the completion of the instrumentation process. This is needed for the plugin to be able to save data collected during instrumentation, similar to JCov saving a template. To do. 2. what is the right way to pass the saver? Currently it is done through JCov properties. 3. how to unit test the exit hook? See com.sun.tdk.jcov.runtime.Collect.init(), where there is a hack right now. 4. how to test instrumentation from the same VM? See _com.sun.tdk.jcov.lib.InstrProxy.instr(String[] , String...)_ 5. allow the instrumentation plugin through all entry points. Right now only _com.sun.tdk.jcov.Instr_ is supported and tested. ------------- Commit messages: - Added instrumentation plugin support for JREInstr and a test - removed test files - Addressed comments, added datasaving lifecycle method. - Instrumentation plugin concept Changes: https://git.openjdk.java.net/jcov/pull/9/files Webrev: https://webrevs.openjdk.java.net/?repo=jcov&pr=9&range=00 Stats: 800 lines in 16 files changed: 756 ins; 1 del; 43 mod Patch: https://git.openjdk.java.net/jcov/pull/9.diff Fetch: git fetch https://git.openjdk.java.net/jcov pull/9/head:pull/9 PR: https://git.openjdk.java.net/jcov/pull/9 From lkuskov at openjdk.java.net Wed Mar 10 20:01:19 2021 From: lkuskov at openjdk.java.net (Leonid Kuskov) Date: Wed, 10 Mar 2021 20:01:19 GMT Subject: RFR: Instrumentation plugin concept In-Reply-To: References: Message-ID: <8_yjI0NxJn6WnYLrovSl8x0DZQ-Udg2mgnYWwdMg88k=.81cf1c13-212e-4e34-9366-2063c6f6d4a1@github.com> On Wed, 17 Feb 2021 15:55:56 GMT, Alexandre Iline wrote: > These changes are introducing a concept of an instrumentation plugin into JCov. Instrumentation plugin (defined by _com.sun.tdk.jcov.instrument.InstrumentationPlugin_) represents a logic which specifies what code instrumentation is to be performed by JCov. > > In the current implementation, the concept is only used to define instrumentation **additional** to that which is already done by JCov. The instrumentation performed by such plugins may or may not be relates to the instrumentation already performed by JCov. As such, JCov could be used as only an engine to load and save the code, with the additional instrumentation having nothing to do with code coverage. > > It is also possible to reuse the same concept **within JCov itself**. Depending on the command line option, JCov already inserts very different instrumentations. This is now controlled programmatically such as in _com.sun.tdk.jcov.instrument.DeferringMethodClassAdapter.visitMethod(int, String, String, String, String[])_ method. Such code could possibly benefit from some delegation. This actual suggested change does not suggest any changes related to code instrumentation currently supported by JCov. > > In addition to the instrumentation plugin, the changes suggest a way to specify a logic to save all data collected during the runtime. That is done by reusing _com.sun.tdk.jcov.runtime.JCovSaver_ interface. > > > To better understand the concept perhaps it is helpful to take a look on the test which is suggested as a part of this change: _com.sun.tdk.jcov.instrument.plugin.FieldsTest_ and the accompanying files. The same concept is explained in more details in this draft JEP proposal: https://bugs.openjdk.java.net/browse/JDK-8043291 > > > More work needed. > > Current state of the code is offered solely for the purpose of discussing the concepts of instrumentation plugin. When the concept is generally accepted, more changes to the source are needed and more testing is needed also. > > These are only some of the things which needs to be looked into: > 1. a mechanism is required to notify the plugin about the completion of the instrumentation process. This is needed for the plugin to be able to save data collected during instrumentation, similar to JCov saving a template. To do. > 2. what is the right way to pass the saver? Currently it is done through JCov properties. > 3. how to unit test the exit hook? See com.sun.tdk.jcov.runtime.Collect.init(), where there is a hack right now. > 4. how to test instrumentation from the same VM? See _com.sun.tdk.jcov.lib.InstrProxy.instr(String[] , String...)_ > 5. allow the instrumentation plugin through all entry points. Right now only _com.sun.tdk.jcov.Instr_ is supported and tested. There are comments inlined in code review. Also it would be good to have a working plugin (not just a unit test) that could be used for gathering certain info. Marked as reviewed by lkuskov (Committer). build/build.xml line 315: > 313: > 314: > 315: Actually, build.properties does not contain jcomander.jar property. Please add it. src/classes/com/sun/tdk/jcov/Instr.java line 658: > 656: String pluginClass = opts.getValue(InstrumentationOptions.DSC_INSTR_PLUGIN); > 657: if(pluginClass != null && !pluginClass.isEmpty()) > 658: plugin = (InstrumentationPlugin) Class.forName(opts.getValue(InstrumentationOptions.DSC_INSTR_PLUGIN)).newInstance(); There should be: forName().getDeclaredConstructor().newInstance() Class.newInstance() has been deprecated since 9 src/classes/com/sun/tdk/jcov/instrument/InstrumentationOptions.java line 161: > 159: public final static OptionDescr DSC_INSTR_PLUGIN = > 160: new OptionDescr("instr_plugin", new String[0], "", OptionDescr.VAL_SINGLE, > 161: "TODO"); It's not good idea to put back the empty descriptor for a new option. src/classes/com/sun/tdk/jcov/instrument/InstrumentationParams.java line 111: > 109: } > 110: public InstrumentationParams(boolean innerInvocations, boolean classesReload, boolean dynamicCollect, boolean instrumentNative, boolean instrumentFields, boolean detectInternal, ABSTRACTMODE instrumentAbstract, String[] includes, String[] excludes, String[] callerIncludes, String[] callerExcludes, String[] m_includes, String[] m_excludes, InstrumentationMode mode, String[] saveBegin, String[] saveEnd, InstrumentationPlugin plugin) { > 111: It would be good to follow Java Code Conventions: Avoid lines longer than 80 chars. src/classes/result.xml line 1: > 1: Do we need to have this file in the repository? src/classes/template.xml line 1: > 1: The file looks superfluous. ------------- Changes requested by lkuskov (Committer). PR: https://git.openjdk.java.net/jcov/pull/9 From shurailine at openjdk.java.net Wed Mar 10 20:01:20 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 10 Mar 2021 20:01:20 GMT Subject: RFR: Instrumentation plugin concept In-Reply-To: References: <8_yjI0NxJn6WnYLrovSl8x0DZQ-Udg2mgnYWwdMg88k=.81cf1c13-212e-4e34-9366-2063c6f6d4a1@github.com> Message-ID: On Tue, 23 Feb 2021 16:05:33 GMT, Alexandre Iline wrote: > There are comments inlined in code review. > Also it would be good to have a working plugin (not just a unit test) that could be used for gathering certain info. Thanks for the comments, @lkuskov . Developing an actual plugin may be a lot of work, depending on the plugin. I am planning to embark on implementing "data coverage" concepts, after this is pushed in. Many things need to be resolved for that plugin, including, but not limited to: * support for all data types * mechanism to specify data domains * "template" format and creation * report generation A functional plugin would take a lot to develop, it would be a project on its own, it will not be possible to do it all in one commit. It may even go into a different source repository. Further on, additional changes to JCov itself to use Instrumentation plugin, should also be done by additional commits, not by this one. What I am suggesting, therefore, is to limit this change in its current scope. All questions and comments needs to be resolved first, of course. One thing I agree on is that more tests are needed. I would be happy to work on that. ------------- PR: https://git.openjdk.java.net/jcov/pull/9 From shurailine at openjdk.java.net Wed Mar 10 20:01:20 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 10 Mar 2021 20:01:20 GMT Subject: RFR: Instrumentation plugin concept In-Reply-To: <8_yjI0NxJn6WnYLrovSl8x0DZQ-Udg2mgnYWwdMg88k=.81cf1c13-212e-4e34-9366-2063c6f6d4a1@github.com> References: <8_yjI0NxJn6WnYLrovSl8x0DZQ-Udg2mgnYWwdMg88k=.81cf1c13-212e-4e34-9366-2063c6f6d4a1@github.com> Message-ID: On Tue, 23 Feb 2021 03:04:43 GMT, Leonid Kuskov wrote: > There are comments inlined in code review. > Also it would be good to have a working plugin (not just a unit test) that could be used for gathering certain info. I will be addressing the comments, thank you for catching that. I would also really appreciate if you can comment on a few questions I have mentioned in the description of this change: * what is the right way to pass the saver? Currently it is done through JCov properties. * how to unit test the exit hook? See com.sun.tdk.jcov.runtime.Collect.init(), where there is a hack right now. * how to test instrumentation from the same VM? See com.sun.tdk.jcov.lib.InstrProxy.instr(String[] , String...) > src/classes/com/sun/tdk/jcov/instrument/InstrumentationParams.java line 111: > >> 109: } >> 110: public InstrumentationParams(boolean innerInvocations, boolean classesReload, boolean dynamicCollect, boolean instrumentNative, boolean instrumentFields, boolean detectInternal, ABSTRACTMODE instrumentAbstract, String[] includes, String[] excludes, String[] callerIncludes, String[] callerExcludes, String[] m_includes, String[] m_excludes, InstrumentationMode mode, String[] saveBegin, String[] saveEnd, InstrumentationPlugin plugin) { >> 111: > > It would be good to follow Java Code Conventions: Avoid lines longer than 80 chars. I would be happy to reformat my new added constructor and all the previously existing constructors. Will do. However, the right thing to do would be to rework this class to use builder pattern. I have just created https://bugs.openjdk.java.net/browse/CODETOOLS-7902832 to that extent. ------------- PR: https://git.openjdk.java.net/jcov/pull/9 From shurailine at openjdk.java.net Wed Mar 10 20:09:12 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Wed, 10 Mar 2021 20:09:12 GMT Subject: RFR: Instrumentation plugin concept In-Reply-To: <8_yjI0NxJn6WnYLrovSl8x0DZQ-Udg2mgnYWwdMg88k=.81cf1c13-212e-4e34-9366-2063c6f6d4a1@github.com> References: <8_yjI0NxJn6WnYLrovSl8x0DZQ-Udg2mgnYWwdMg88k=.81cf1c13-212e-4e34-9366-2063c6f6d4a1@github.com> Message-ID: On Wed, 3 Mar 2021 22:04:51 GMT, Leonid Kuskov wrote: >> These changes are introducing a concept of an instrumentation plugin into JCov. Instrumentation plugin (defined by _com.sun.tdk.jcov.instrument.InstrumentationPlugin_) represents a logic which specifies what code instrumentation is to be performed by JCov. >> >> In the current implementation, the concept is only used to define instrumentation **additional** to that which is already done by JCov. The instrumentation performed by such plugins may or may not be relates to the instrumentation already performed by JCov. As such, JCov could be used as only an engine to load and save the code, with the additional instrumentation having nothing to do with code coverage. >> >> It is also possible to reuse the same concept **within JCov itself**. Depending on the command line option, JCov already inserts very different instrumentations. This is now controlled programmatically such as in _com.sun.tdk.jcov.instrument.DeferringMethodClassAdapter.visitMethod(int, String, String, String, String[])_ method. Such code could possibly benefit from some delegation. This actual suggested change does not suggest any changes related to code instrumentation currently supported by JCov. >> >> In addition to the instrumentation plugin, the changes suggest a way to specify a logic to save all data collected during the runtime. That is done by reusing _com.sun.tdk.jcov.runtime.JCovSaver_ interface. >> >> >> To better understand the concept perhaps it is helpful to take a look on the test which is suggested as a part of this change: _com.sun.tdk.jcov.instrument.plugin.FieldsTest_ and the accompanying files. The same concept is explained in more details in this draft JEP proposal: https://bugs.openjdk.java.net/browse/JDK-8043291 >> >> >> More work needed. >> >> Current state of the code is offered solely for the purpose of discussing the concepts of instrumentation plugin. When the concept is generally accepted, more changes to the source are needed and more testing is needed also. >> >> These are only some of the things which needs to be looked into: >> 1. a mechanism is required to notify the plugin about the completion of the instrumentation process. This is needed for the plugin to be able to save data collected during instrumentation, similar to JCov saving a template. To do. >> 2. what is the right way to pass the saver? Currently it is done through JCov properties. >> 3. how to unit test the exit hook? See com.sun.tdk.jcov.runtime.Collect.init(), where there is a hack right now. >> 4. how to test instrumentation from the same VM? See _com.sun.tdk.jcov.lib.InstrProxy.instr(String[] , String...)_ >> 5. allow the instrumentation plugin through all entry points. Right now only _com.sun.tdk.jcov.Instr_ is supported and tested. > > Marked as reviewed by lkuskov (Committer). @lkuskov , I have added another commit to support JREInstr. I think this is in a good enough shape to be integrated into the main JCov repository. Would you agree to that? The only functional change to the behavior, if no plugin is specified, is in com.sun.tdk.jcov.runtime.Collect.init(): https://github.com/openjdk/jcov/pull/9/files#diff-3ccc940162578203e7797c295946dcfdfe788c085bf2cf741b28c52609d2080d I have not found a scenario where this change would be harmful. The change, however, needed for the tests to work. ------------- PR: https://git.openjdk.java.net/jcov/pull/9 From shurailine at openjdk.java.net Thu Mar 11 19:53:10 2021 From: shurailine at openjdk.java.net (Alexandre Iline) Date: Thu, 11 Mar 2021 19:53:10 GMT Subject: Integrated: Instrumentation plugin concept In-Reply-To: References: Message-ID: On Wed, 17 Feb 2021 15:55:56 GMT, Alexandre Iline wrote: > These changes are introducing a concept of an instrumentation plugin into JCov. Instrumentation plugin (defined by _com.sun.tdk.jcov.instrument.InstrumentationPlugin_) represents a logic which specifies what code instrumentation is to be performed by JCov. > > In the current implementation, the concept is only used to define instrumentation **additional** to that which is already done by JCov. The instrumentation performed by such plugins may or may not be relates to the instrumentation already performed by JCov. As such, JCov could be used as only an engine to load and save the code, with the additional instrumentation having nothing to do with code coverage. > > It is also possible to reuse the same concept **within JCov itself**. Depending on the command line option, JCov already inserts very different instrumentations. This is now controlled programmatically such as in _com.sun.tdk.jcov.instrument.DeferringMethodClassAdapter.visitMethod(int, String, String, String, String[])_ method. Such code could possibly benefit from some delegation. This actual suggested change does not suggest any changes related to code instrumentation currently supported by JCov. > > In addition to the instrumentation plugin, the changes suggest a way to specify a logic to save all data collected during the runtime. That is done by reusing _com.sun.tdk.jcov.runtime.JCovSaver_ interface. > > > To better understand the concept perhaps it is helpful to take a look on the test which is suggested as a part of this change: _com.sun.tdk.jcov.instrument.plugin.FieldsTest_ and the accompanying files. The same concept is explained in more details in this draft JEP proposal: https://bugs.openjdk.java.net/browse/JDK-8043291 > > > More work needed. > > Current state of the code is offered solely for the purpose of discussing the concepts of instrumentation plugin. When the concept is generally accepted, more changes to the source are needed and more testing is needed also. > > These are only some of the things which needs to be looked into: > 1. a mechanism is required to notify the plugin about the completion of the instrumentation process. This is needed for the plugin to be able to save data collected during instrumentation, similar to JCov saving a template. To do. > 2. what is the right way to pass the saver? Currently it is done through JCov properties. > 3. how to unit test the exit hook? See com.sun.tdk.jcov.runtime.Collect.init(), where there is a hack right now. > 4. how to test instrumentation from the same VM? See _com.sun.tdk.jcov.lib.InstrProxy.instr(String[] , String...)_ > 5. allow the instrumentation plugin through all entry points. Right now only _com.sun.tdk.jcov.Instr_ is supported and tested. This pull request has now been integrated. Changeset: 8deab262 Author: Alexandre Iline URL: https://git.openjdk.java.net/jcov/commit/8deab262 Stats: 800 lines in 16 files changed: 756 ins; 1 del; 43 mod Instrumentation plugin concept Reviewed-by: lkuskov ------------- PR: https://git.openjdk.java.net/jcov/pull/9