Adding Microbenchmarks to the JDK forest/trees (JEP-230)

roger riggs roger.riggs at oracle.com
Tue Dec 2 14:48:20 UTC 2014


Hi Staffan,

An earlier issue was keeping tests in sync with the code under test, hence
the use of test directories within each repository.
I think a structure in which the benchmarks for some function and the 
function
itself are in the same repository that is easier to understand and 
maintain.

$.02, Roger


On 12/1/2014 7:08 PM, Staffan Friberg wrote:
> Hi,
>
> Hopefully this is the right list for this discussion.
>
> As part of adding Microbenchmarks to the OpenJDK source tree, I'm 
> trying to understand how we best would add the benchmark sources to 
> the existing OpenJDK tree structure.
>
> Since the microbenchmark suite will cover all parts of the JDK, 
> covering HotSpot, JDK libraries and Nashorn, it would be preferred to 
> add the microbenchmark directory as a new top level directory. 
> Something similar to the following structure. Having "benchmark" as 
> the top-level directory would allow us to later add different types of 
> benchmarks without colliding with the microbenchmark suite.
>
> <openjdk-root>/
>    benchmark/microbenchmark/...
>    hotspot/...
>    jdk/...
>    nashorn/...
>
> With this as the premise I can see the following 3 options for how 
> this could be added to the source code layout
>
> 1. Part of jdk-root repository
>      * Only makes sense if we want to move in a direction with fewer
>        trees (and eventually a single tree)
> 2. Part of another already existing tree
>      * Not sure if this is possible without converting and moving the
>        directory to a subdirectory of that tree
> 3. New tree in the forest/tree structure
>      * Most logical option as it follows the current setup and structure
>
>
> Anyone have any comments and/or concerns on the suggested directory 
> location and the tree structure in option 3.
>
> Would the build-dev team be the right group to later help setup a new 
> tree if decided to be the right way to go?
>
> Regards,
> Staffan
>




More information about the build-dev mailing list