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
Scott Morgan wrote:
Hi Heinz,
Can you ask Daniel and Chris if I (Adligo Inc/adligo.org
<http://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/560B5E0A.5090309%40javaspecialists.eu.
For more options, visit https://groups.google.com/d/optout.
