Restructuring to provide per-serializer classloading.

[ghost]

Hello Eishay

Firstly, thanks very much for this tool - it's really useful. We use it quite a bit to benchmark new releases of our own code to ensure that there are no regressions.

I saw that there were the beginnings of providing per-serializer classloading. To make our testing easier I went ahead and implemented something that works for me. Of course it may not be good for every flavor of serializer, but it seems to be OK. (Although Scala doesn't work - yet :) )

Admittedly it's not complete but I thought you might be interested in taking a look and perhaps even using it in the mainline code.

Thanks --Jens

Changes:

Moved various core classes into a 'core' package. These classes get loaded by the system classloader. Created a lib-core directory which contains the cks jars. These jars are also loaded by the system classloader.

As part of the build, the serializer specific classes are moved to build/bytecode/main/sx in order to easily reference them via a path which doesn't contain any core classes. This path is passed in via the system property loader.classpath. Each serializer is initialized using its own classloader and this path. Each serializer classloader is also given the jars in lib. The classes in build/bytecode/main/sx and jars in lib cannot be referenced by the system classloader otherwise this mechanism breaks.

Only those serializers which are referenced using -include are actually initialized.

There is a mapping between serializer name and the implementing class (see BenchmarkBase.java). Unfortunately this serialzer name doesn't get used when initializing the actual class so the name in the class still needs to be maintained. For some serializers, one register invocation actually produces multiple tests, each with a different name. Need to figure out how to remove this redundancy.

Only some of the serializers have been tested using this new structure.

Scala doesn't work.

[cowtowncoder]

On Wed, Mar 21, 2012 at 7:08 AM, Jens Deppe reply@reply.github.com wrote:

Hello Eishay

Firstly, thanks very much for this tool - it's really useful. We use it quite a bit to benchmark new releases of our own code to ensure that there are no regressions.

I saw that there were the beginnings of providing per-serializer classloading. To make our testing easier I went ahead and implemented something that works for me. Of course it may not be good for every flavor of serializer, but it seems to be OK. (Although Scala doesn't work - yet :) )

Admittedly it's not complete but I thought you might be interested in taking a look and perhaps even using it in the mainline code.

While I have not yet checked out changes, I think this is great -- I had started to look into doing this, but gave up at some point. Good that you picked it up, since to get really stable and solid results, tests should be run using separate class loaders (if not JVMs).

As you pointed out, there are some issue wrt bundling of codecs by some implementations. These should be possible to resolve by bit of refactoring.

-+ Tatu +-

[cowtowncoder]

Hi Jens! I was about to pull this request, but unfortunately it looks like some commits conflict with it. If you could update the fork and let me know, I'll merge it as soon as that can be done cleanly? Apologies for slow delay, was assuming someone else would merge it.