Currently JPRT has intimate knowledge about the original PRT tests run by hotspot jobs.

The goal here is to remove that knowledge from JPRT internals and move it into the hotspot/test/Makefile so that anyone could run the tests the same way that JPRT does. See suggested fix for how jvm98 might change. This simplifies JPRT and enables the hotspot developer to run tests manually and be a little less tied to JPRT availability.

Further changes would be to define the standard run flavors instead of defining a PRT-config file in the test bundles, so that running jvm98 is just downloading and installing the testbase, and repeatedly running that test with different run flavors.
Currently there is just c1 and c2 run flavors, defined as follows:

# The default run flavors
jprt.run.flavors=c1,c2
jprt.run.flavor.c1.option=-client
jprt.run.flavor.c2.option=-server
jprt.solaris.sparcv9.run.flavors=c2
jprt.solaris.x64.run.flavors=c2
jprt.linux.x64.run.flavors=c2
jprt.windows.x64.run.flavors=c2

This could be expanded to include all the various run flavors, like how jvm98 is run, e.g. adding tiered

# The default run flavors
jprt.run.flavors=c1,c2,t1
jprt.run.flavor.c1.option=-client
jprt.run.flavor.c2.option=-server
jprt.run.flavor.t1.option=-XX:+TieredCompilation
jprt.solaris.sparcv9.run.flavors=c2,t1
jprt.solaris.x64.run.flavors=c2,t1
jprt.linux.x64.run.flavors=c2,t1
jprt.windows.x64.run.flavors=c2,t1

Variations on the testcase arguments and how the testcase is run would be handled in the hotspot/test/Makefile. So you could have multiple "jvm98" targets like "jvm98_variation1", "jvm98_variation2", etc.

Time limits may be something that will need to be added to JPRT for specific targets, easy feature to add when needed.