Hi Peter,
can you quantify: " is almost no additional runtime overhead."?
On Wed, Oct 8, 2014 at 11:38 AM, Peter Levart
wrote:
> On 10/05/2014 10:44 PM, Peter Levart wrote:
>
>> The 3rd report shows a result of experimental AtomicIntegerFieldUpdater
>> implementation which loads new VM-anonymou
On 10/08/2014 01:19 PM, Doug Lea wrote:
On 10/08/2014 05:38 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java
Paul Sandoz has been working on VarHandles (like MethodHandles)
for similar p
On 10/08/2014 12:23 PM, √iktor Ҡlang wrote:
Hi Peter,
can you quantify: " is almost no additional runtime overhead."?
Limited to AtomicIntegerFieldUpdater, all individual modifying
operations that map directly to Unsafe intrinsics benchmarked with JMH
tests run at same speed as normal Java v
On 10/08/2014 05:38 AM, Peter Levart wrote:
http://cr.openjdk.java.net/~plevart/jdk9-dev/AtomicFieldUpdater.AccessChecks/AnonClassPerCclass/AtomicIntegerFieldUpdater.java
Paul Sandoz has been working on VarHandles (like MethodHandles)
for similar purposes. Possibly even the same purposes.
Se
On 10/05/2014 10:44 PM, Peter Levart wrote:
The 3rd report shows a result of experimental
AtomicIntegerFieldUpdater implementation which loads new VM-anonymous
class for each new instance which allows VM compiler to specialize
code for a particular field. Such implementation is nearly as fast a
On 10/04/2014 05:15 AM, Alan Bateman wrote:
On 03/10/2014 08:13, David M. Lloyd wrote:
:
Why the problem occurs
--
The root of the problem traces back to
SecurityManager.checkMemberAccess(). This method is the one
remaining method in all of SecurityManager which uses the
On 10/03/2014 10:15 PM, Alan Bateman wrote:
On 03/10/2014 08:13, David M. Lloyd wrote:
:
Why the problem occurs
--
The root of the problem traces back to
SecurityManager.checkMemberAccess(). This method is the one remaining
method in all of SecurityManager which uses the ca
On 03/10/2014 08:13, David M. Lloyd wrote:
:
Why the problem occurs
--
The root of the problem traces back to
SecurityManager.checkMemberAccess(). This method is the one remaining
method in all of SecurityManager which uses the calling class context
(stack) in order to de
Thanks for the careful explanation. In short, the current checks
reject reasonable EE usages, which can lead users to widen
permissions, which can lead to less overall security.
The solution to inspect other caller frames seems OK to me.
But acceptance into OpenJDK requires approval from securit
This discussion fizzled out last time it happened (2011 or something?).
So to avoid that happening again, I'm going to (hopefully clearly and
in simple unambiguous terms) explain what the problem is, why it should
be fixed, why the problem occurs, and exactly what should be done to fix
the pro
10 matches
Mail list logo
