This code has been reviewed and submitted internally. Feel free to discuss on the PR and we can submit follow-up changes as necessary.
Commits:
Get rid of Platform, splitting its functionality between Device and Vm (new).
Both Device and Vm are abstract types which take an configuration object when created:
- Device takes a DeviceConfig and currently has one implementation: LocalDevice.
- Vm takes a VmConfig and has two implementations: Jvm and AndroidVm.
LocalDevice currently must consider the case where it is actually running on an Android device until we're able to stop using the existing Android solution of running the Caliper runner directly on the device.
The type of Vm that is instantiated for a given VmConfig depends on the Device in use:
- LocalDevice supports both Jvm and AndroidVm. If the VmConfig does not have a VmType set (there's no "vm..type=" in the user's configration for the VM), LocalDevice defaults to VmType.JVM when running on a non-Android machine and to VmType.ANDROID when running on an Android device. This is primarily for backwards compatibility since prior to now, there was no such thing as setting a VM type in configuration files.
- When an Android/ADB-device is created, it will only support VmType.ANDROID.
In general, the Device implementation is responsible resolving absolute paths to VM executables based on its configuration and the VM's configuration. It's also responsible for creating a default VmConfig in the case that the user doesn't specify a custom VM config to use.
The Vm implementation is responsible for determining other things about executing a VM; primarily things related to what flags to pass to the VM executable.
This CL also changes a few things about how VMs are configured. VMs can now have an "executable" field in their configuration. For JVMs, this generally shouldn't need to be set, because it will default to "java". For Android VMs on Android devices, different VMs aren't really differentiated by "VM home directory" the way they are for JVMs. Rather, the VM executables are all in /system/bin, so we want to create different configurations that are set to different executables (e.g. one for "dalvikvm", one for "app_process", etc.). The DalvikPlatform implementation of Platform had hacky ways of working around the lack of a feature like this; this change makes Caliper support it naturally.
ca2f6bc9edfc6fdd53460ee83e8bb2c09a4a8588
This code has been reviewed and submitted internally. Feel free to discuss on the PR and we can submit follow-up changes as necessary.
Commits:
Get rid of Platform, splitting its functionality between Device and Vm (new). Both Device and Vm are abstract types which take an configuration object when created: - Device takes a DeviceConfig and currently has one implementation: LocalDevice. - Vm takes a VmConfig and has two implementations: Jvm and AndroidVm. LocalDevice currently must consider the case where it is actually running on an Android device until we're able to stop using the existing Android solution of running the Caliper runner directly on the device. The type of Vm that is instantiated for a given VmConfig depends on the Device in use: - LocalDevice supports both Jvm and AndroidVm. If the VmConfig does not have a VmType set (there's no "vm..type=" in the user's configration for the VM), LocalDevice defaults to VmType.JVM when running on a non-Android machine and to VmType.ANDROID when running on an Android device. This is primarily for backwards compatibility since prior to now, there was no such thing as setting a VM type in configuration files.
- When an Android/ADB-device is created, it will only support VmType.ANDROID.
In general, the Device implementation is responsible resolving absolute paths to VM executables based on its configuration and the VM's configuration. It's also responsible for creating a default VmConfig in the case that the user doesn't specify a custom VM config to use.
The Vm implementation is responsible for determining other things about executing a VM; primarily things related to what flags to pass to the VM executable.
This CL also changes a few things about how VMs are configured. VMs can now have an "executable" field in their configuration. For JVMs, this generally shouldn't need to be set, because it will default to "java". For Android VMs on Android devices, different VMs aren't really differentiated by "VM home directory" the way they are for JVMs. Rather, the VM executables are all in /system/bin, so we want to create different configurations that are set to different executables (e.g. one for "dalvikvm", one for "app_process", etc.). The DalvikPlatform implementation of Platform had hacky ways of working around the lack of a feature like this; this change makes Caliper support it naturally.
ca2f6bc9edfc6fdd53460ee83e8bb2c09a4a8588