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


Thanks,
/Staffan


On 21 aug 2012, at 23:47, BILL PITTORE <[email protected]> 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.
> 
> http://cr.openjdk.java.net/~bpittore/7154641/webrev.00/
> 
> thanks,
> bill
> 

Reply via email to