Re: ByteWatcher from JCrete

[Scott Morgan]

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

[Dr Heinz M. Kabutz]

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 2012
http://www.javaspecialists.eu
Tel: +30 69 75 595 262
Skype: kabutz

[Daniel Shaya]

+1