Bug ID: JDK-4900152 performance of getStackAccessControlContext() needs to be improved
`
`Products and Services
`
`Downloads
`
`Store
`
`Support
`
`Education
`
`Partners
`
`About
`
`Oracle Technology Network
`
`Oracle Technology Network
`
`Java
`
`Java SE
`
`Community
`
`Bug Database
`
`United States
`
`Communities
`
`I am a...
`
`I want to...
`
`Secure Search
`
`Community
`
`Java Embedded
`
`Java Card
`
`Java DB
`
`Java EE
`
`JavaFX
`
`Java Magazine
`
`Java ME
`
`Java SE Advanced & Suite
`
`Java SE
`
`Java SE Support
`
`Java Advanced
`
`Java TV
`
`New to Java
`
`Web Tier
`
`JDK-4900152 : performance of getStackAccessControlContext() needs to be
`improved
`
`Details
`
`Type:
`Status:
`Project Name:
`Component:
`Sub-Component:
`Priority:
`Resolution:
`Affected Versions:
`Fixed Versions:
`
`Bug
`Closed
`JDK
`hotspot
`runtime
`P4
`Won't Fix
`5.0
`
`Submit Date:
`Updated Date:
`Resolved Date:
`OS:
`CPU:
`
`2003-08-01
`2004-07-29
`2004-07-29
`solaris_8
`sparc
`
`Related Reports
`Relates:
`JDK-4785326 - constant creation of AccessControlContexts from native code is
`expensive
`JDK-4981972 - JVM_DoPrivileged freq aquires the jni handle lock causing perf prob
`
`Relates:
`
`Sub Tasks
`
`Description
`getStackAccessControlContext() is a major component in the cost of doing
`security checks. Its performance needs to be improved to lower the overhead
`of enabling the security manager.
`
`Comments
`EVALUATION
`There appears to be very little that can be done to improve the
`stack walking that is done in this VM service. There is quite
`a lot of checking required for each frame. As we walk the stack
`we must determine if the frame is compiled, interpreted, deopted.
`We must then find the pc, look up the code blob associated with
`the pc.
`The only overhead that I could possibly avoid is the codeblob
`lookup. Since we must match the frame id and method when searching for
`a privileged context, we could skip the method lookup until we
`find a frame match. Unfortunately, the codeblob lookup takes
`only .7% of the time running a small test program.
`Once way to significantly reduce the overhead of the
`getStackAccessControlContext() call is to set a privileged context.
`This call keeps the VM from scanning the entire threads stack.
`Unfortunately, this call is almost as expensive as the
`getStackAccessControlContext().
`Is is possible for the security system to notify the VM that a thread
`has all permissions so we can simply return NULL when a call to
`getStackAccessControlContext() is made?
`There is quite a lot of extra overhead in the DoPrivileged call. Since
`the VM must call back into Java code, we must set up a java call wrapper,
`create JNI handle array. If the secutiry model was changed
`to call into the VM to push and pop a privileged context and executed the
`action.run() call in Java code, this callback overhead could be avoided.
`There is some reluctance to adopt this model in the security team since
`there would be some work required in the VM to pop contexts in the event
`of an Async exception. I belive that this can be handled in the hotspot
`VM without too much work. I prototyped this different model and sped
`up the DoPrivileged call by around 50%.
`###@###.### 2003-08-18
`Some improvement was done in the 1.5 release to reduce the overhead
`of the JVM_DoPrivileged call by eliminating a lock that the VM was taking
`when allocating a block of jni handles.
`There is more work that needs to be done in the VM compilers to allocate
`a frame on the java stack to maintain the privileged context. This
`work was not completed in time for the 1.5 code freeze. I am retargeting
`this work for 1.5.1. I am also lowering the priority of this bug since this
`
`http://bugs.java.com/view_bug.do...
`
`5/6/2016
`
`Ericsson Ex. 2016, Page 1
`TCL et al. v Ericsson
`IPR2015-01605
`
`

`
`Bug ID: JDK-4900152 performance of getStackAccessControlContext() needs to be improved
`
`call does not appear as a high % of time in the analyzer dumps I received
`from Scott Oaks.
`
`The latest specJAppserver specification does not require the security manager
`to be on while running the benchamrk. As a result of this fact plus the fact
`the the overhead has been reduced in 1.5, I am going to close this bug.
`
`2004-07-30
`
`Subscribe About Oracle Careers Contact Us Site Maps Legal Notices Terms of Use Your Privacy Rights
`
`Oracle Mobile
`
`http://bugs.java.com/view_bug.do...
`
`5/6/2016
`
`Ericsson Ex. 2016, Page 2
`TCL et al. v Ericsson
`IPR2015-01605