StubToolkit must go!
david.dehaven at oracle.com
Wed Feb 6 07:57:13 PST 2013
> Another big issue is that right now each test class is fired up in its own VM and takes 10x longer (or thereabouts) to execute than if the tests could all just run in the same VM. Some tests need their own VM (related to initialization etc where we cannot easily reinitialize some code on subsequent test runs), whereas most of them could run concurrently. I'm looking into JTReg as the main system for invoking our tests, which is capable of calling TestNG tests or Jemmy tests or any other type of test out there we need to run (and is the same system used by OpenJDK). I mention this, although I am not going to do it yet (just in case those of you with loads of jtreg experience can help guide my way :-)).
The problem with running them all in the same VM is when something behaves poorly it tends to cascade and you end up with a big snowball effect of a bunch of problems and failures occurring later on, especially irritating to track down if the poorly behaving test does not cause a failure itself.
I fully support moving to JTReg, my short stint in core-libs learned me it's on a slightly higher shelf than what we have now :)
Another thought that was recently brought up is running JPRT jobs before integration, since we're integrated with the JDK now and becoming more so by the week. I believe that would require moving to jtreg and quite possibly some changes to JPRT.
More information about the openjfx-dev