+1 On 30 September 2015 at 04:59, Dr Heinz M. Kabutz <[email protected]> wrote:
> Absolutely no problem Scott! I would recommend just forking it and then > doing what you want with it. We have published it under Apache 2.0, so > that makes it very easy to create derivate works from it. > > About your Byte Code idea - it's been done :-) Check the bottom of my > online newsletter for a link: > http://www.javaspecialists.eu/archive/Issue232.html > > Regards > > Heinz > -- > Dr Heinz M. Kabutz (PhD CompSci) > Author of "The Java(tm) Specialists' Newsletter" > Sun/Oracle Java Champion since 2005 > JavaOne Rock Star Speaker 2012http://www.javaspecialists.eu > Tel: +30 69 75 595 262 > Skype: kabutz > > > > Scott Morgan wrote: > > Hi Heinz, > > Can you ask Daniel and Chris if I (Adligo Inc/adligo.org) can get > permission to modify and add some of the ByteWatcher code in Tests4j in the > future. I will mention your git project and your names in the source file > comments if I do, of course. > I am guessing I will not get to memory testing for a few years at this > point, but it looks like a good starting point and I have been looking for > something like this for about 10 years. > I think I would need to modify it just a bit for the each Trial and > Test thread pair, also it wouldn't work when Trial/Tests pairs were running > concurrently... > > Another approach I was daydreaming a bit about some sort of > ASM/bytecode instrumentation approach to calculating memory > allocations/references. Although daydreaming was about as far as I got, > heres a summary after reading your newest article; > > class Widget extends Object > > original test bytecode: > load class Widget > allocate byte array in new Widget A constructor > remove all references to new Widget A > > instrumented test bytecode: > get static reference to mbean when loading class Widget > allocate byte array in new Widget A > inform mbean byte array was allocated in Widget A on test thread 1 (is > this even possible, how to get the long term java 'pointer' from byte > code? I haven't done the leg work on this one.) > inform mbean Widget A is referenced by test bytecode on test thread 1 > inform mbean Widget A is no longer referenced by test bytecode on test > thread 1 > > Then the test could check for allocations, objects still referenced and > calculate usage , assert for 'leaks' or excessive allocation/garbage > collection. This could also potentially work in Tests4j user Runnable's by > taking a thread tree into account; > Trial Thread > User's Thread (pool's etc) > User's Thread's Thread (pool's etc) > Test Thread > > The first major issue with this approach in Tests4j is that it would need > to be > integrated with the code coverage instrumentation, otherwise > instrumentation would need to occur twice and the two instrumenters would > probably never get along very well [or at all :(]. > > Did you discuss anything like this with Daniel and Chris? > > Also does anyone from the jacoco group have any comments on my idea? > > Testing without the ability to assert memory usage allocation etc at a low > level has always bugged me. I guess the current 'work around' for Tests4j > is to have your trial (or trial run) simply start up another JVM with the > application to be tested with a profiler attached and then make assertions > about the JVM through the profiler api [something that I have not done yet > :) ]. > > For a third approach I suppose I could add a @MemoryTest annotation > which would cause the Tests4j Trial/Test pair to run in a another JVM (on > the same machine) using using your modified git project. I wonder how many > JVMs my computer could handle at once. > > Cheers and Thanks for working on this problem, > Scott > > > > > > > > -- You received this message because you are subscribed to the Google Groups "JaCoCo and EclEmma Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jacoco/CAG_E9S4F3Za2BELE%3D%2BraQ3%3DCVXF_yb9gQWhtCYq%2BUFMzG%3DGDQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
