Code review for SA changes to allow for new processor architectures (7154641)
staffan.larsen at oracle.com
Wed Aug 22 01:20:12 PDT 2012
I like the idea of using reflection. How much work would it be to make the change for the existing platforms as well? I don't really like that there are two different code paths. Also, you only made the change for Linux.
Some other comments:
LinuxCDebugger.java - This change would return null on non-supported cpus instead of throwing an exception with an error message. The error message is more user-friendly.
LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change?
LinuxThreadContextFactory.java, RemoteDebuggerClient.java, HotSpotAgent.java, HTMLGenerator.java - include the name of the CPU or machine type that wasn't found in the exception message
VM.java and vmStructs.cpp - Looks like an unrelated change.
saproc.make:94 - weird indentation
On 21 aug 2012, at 23:47, BILL PITTORE <bill.pittore at oracle.com> wrote:
> These changes allow for the (easier) addition of new processor types to SA other than the standard x86, amd64 and sparc. By using reflection, it is not necessary to instantiate the new class directly in the existing code. Rather the class name is derived from the cpu/os name and is loaded and the constructor called. Note that the existing cpus (x86, amd64, and sparc) code was not modified. Only newly added cpus would go through the reflection code path.
More information about the hotspot-runtime-dev