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/CANEdHmgzfqGdg3wH2u%2BKeKTE9SNeg_a6_ManGkMEYshKCy4gbw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
