Code review for SA changes to allow for new processor architectures (7154641)

BILL PITTORE bill.pittore at
Wed Aug 22 09:13:11 PDT 2012

Updated the webrev at

On 8/22/2012 4:20 AM, Staffan Larsen wrote:
> 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.
We only made changes to get some embedded platforms supported. Right now 
that's only Linux. Someone else asked a similar question about the code 
paths. We (embedded) didn't want to make too many changes to already 
running/working code for x86, amd64 and sparc on Linux, BSD, Windows, 
and solaris. It was also our understanding that your team is in the 
process of evaluating where to go with SA so it seemed best to just make 
the minimal changes. If using reflection works into your plans going 
forward someone (your team?) could implement it for all os/cpu combos.
> Some other comments:
> - 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.
I added a comment here. The exception for unknown cpu would be thrown by I changed the message in that file as 
per below.
> LinuxDebuggerLocal.c and libproc.h - I don't understand why these changes were made. Probably came from some other change?
In the case of a new cpu, there would be a platform specific version of


that would be called by the Java code to get the processor registers. 
Likewise, the functions throw_new_debugger_exception() and 
get_proc_handle() are exported to the platform specific code.
>,,, - include the name of the CPU or machine type that wasn't found in the exception message
> and vmStructs.cpp - Looks like an unrelated change.
Actually needed for stack walking on PPC.
> saproc.make:94 - weird indentation

> Thanks,
> /Staffan
> On 21 aug 2012, at 23:47, BILL PITTORE<bill.pittore at>  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.
>> thanks,
>> bill

More information about the hotspot-runtime-dev mailing list