GitLab

A trace with a different object ID and location should have a different
ID.

We check that the ids are indeed different if we generate
two benchmarks correctly

Removed double iteration over all benchmarks to build the list of
benchmark indexes.

Also fixed a broken switch statement.

Was necessary to enable serialization

The test writes benchmarks to memory and then reads them

Means that deserializing from memory is also possible

Black holes are not member of BCBenchmarkPackage anymore, they are
handled by the class running the benchmarks, and passed as an argument
to runBenchmark()

One function iterated two times over a stream, causing an error.

We want to have serializable benchmarks to avoid too much reloading when
running them with JMH

Streams are better for performance reasons apparently. They are also
more idiomatic than sequences

We used to have traces generated based on the allocation site, which
makes no sense. Now, we use the object id (column "id") to identify
the traces, so that a trace is created for each object in the program.

Running benchmarks from a file of traces should work as expected,
each type of benchmark is selected and the correct traces are ran.

(One problem might remain, which is loading too the trace file too many
times...)

A class for running benchmarks that involve a Set collection.

They just check that loading a benchmark from a trace gets is a
benchmark we can run.

This subproject is about JMH evaluation of benchmarks built with
existing software traces.

Moving the source code to the 'core' subproject broke some tests
so I fixed the paths in the files.

Re-implemented a way similar as the way used for the
JMH plugin, so that the options for benchmarking are in
the build script.

/Finally/ managed to implement my own!

You would think that the order of the source files does not matter
but it does! You should compile the Java first...

The build scripts is split in two parts, one for each subprojects

This project will contain the main JBrainy libraries

Running gradle with java 8 causes complaints

JBrainy now supports bytecode benchmark generation, and
benchmark generated based on experimentally derived Markov chains.

Data is checked and parsed before doing normalization.

This data is from using markov chains for generating benchmarks