RFE: 4508774: Implementation for GetOperandStack

[serguei.spitsyn at oracle.com]

Hi Jan,

I was told that you are not allowed to contribute until you sign an OSA.
This is a link to follow:
   http://openjdk.java.net/contribute/

I'm deleting the attachment from the bug report at the moment. Sorry. :(

Thanks,
Serguei

On 2/10/14 3:36 PM, serguei.spitsyn at oracle.com wrote:
> Hi Jan,
>
> Thank you for contributing a suggested fix for this enhancement!
> I've attached your diff into the bug report file getOpStack.patch.
> Of course, we will take care and make sure the final fix is type safe.
>
> In case the attachment was removed from the mailing list.
> Here is an external link to the diff:
> http://pastebin.com/fbDd7mU3
>
> The above link is helpful as your original diff was removed from the 
> email.
>
> Thanks,
> Serguei
>
>
> On 2/10/14 9:21 AM, Jan Siersch wrote:
>> Hi all,
>>
>> this post is about a feature request for JVMTI to allow access to the 
>> operand stack:
>> https://bugs.openjdk.java.net/browse/JDK-4508774
>>
>> As part of a project I'm working on, I have implemented a set of 
>> functions, namely GetOperand<Type>, which provide the requested 
>> functionality, and I would like to provide this implementation to the 
>> OpenJDK project. As I am not a regular contributor to the OpenJDK 
>> project, I do not have an account for the bug tracker and cannot post 
>> my code there.
>>
>> I have attached a diff with the modified hotspot source code to this 
>> e-mail. This implementation adds a new function category "Operand 
>> Stack" to JVMTI that contains 5 functions (GetOperandObject, 
>> GetOperandInt, GetOperandLong, GetOperandFloat, GetOperandDouble) 
>> which can be used the same way as the corresponding GetLocal<Type> 
>> functions.
>>
>> All changes to the source files are purely additive. No existing 
>> functions are modified. One new VM Operation "GetOperand" is added 
>> and implemented. The changes are based on the "JDK 7 Updates Master" 
>> branch. I have compiled OpenJDK locally with these changes and had no 
>> problems with them.
>>
>> However this implementation still has one drawback: the functions are 
>> not type-safe, as I was unable to find the necessary information 
>> within hotspot to do proper type-checking of operands. For me this is 
>> not a problem, because in my project I have a way of inferring 
>> operand types externally, but for proper production code 
>> type-checking should be added (there is a FIXME in the added source 
>> for this purpose).
>>
>> I hope someone reading this list has the time to look at this code 
>> and if they find it suitable, to integrate it into the OpenJDK 
>> project. About licensing: you may use this code in whatever way, 
>> shape or form you see fit.
>>
>> Regards,
>> Jan
>