RFR (S) 8025112: JSR 292 spec updates for security manager and caller sensitivity
Christian Thalinger
christian.thalinger at oracle.com
Wed Oct 2 12:17:57 PDT 2013
Thank you for doing this; it is much clearer now. Looks good.
On Oct 1, 2013, at 10:19 PM, John Rose <john.r.rose at oracle.com> wrote:
> Chris Thalinger suggested removing the new booleans from the changed "getDirectMethod" call sites and instead put the intended usage into the method names, e.g., "getDirectMethodNoSecurityManager". The result is more clearly correct and maintainable.
>
> Here is the respin:
> http://cr.openjdk.java.net/~jrose/8025112/webrev.01
>
> — John
>
> On Oct 1, 2013, at 3:15 PM, John Rose <john.r.rose at oracle.com> wrote:
>
>> This change updates the javadoc to reflect previous changes in the behavior of the security manager, especially with respect to caller sensitivity.
>>
>> It also adjusts some unit tests.
>>
>> The key change is to the order of the security manager logic. The purpose is to align the "bytecode behavior" of method handles more closely with the native behavior of the corresponding bytecode instructions. This means that "fully trusted" method handles do not incur security checks if they are equivalent to bytecodes that the user could have written.
>>
>> The API spec. and security rules have been internally reviewed. This is a review of implementation and unit tests.
>>
>> http://cr.openjdk.java.net/~jrose/8025112/webrev.00
>>
>> For more background, see my JavaOne presentation:
>> http://cr.openjdk.java.net/~jrose/pres/201309-IndyUpdate.pdf
>>
>> Thanks,
>> — John
>
> _______________________________________________
> mlvm-dev mailing list
> mlvm-dev at openjdk.java.net
> http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
More information about the hotspot-compiler-dev
mailing list