> On 2 Jan 2017, at 03:25, Claes Redestad wrote:
>
>
>
> Hi Peter,
>
> agreed, it appears this assert could be replaced by a test - similar to what
> was already
> done for VarHandle.AccessMode[1] - which might increase robustness of early
> use of
> VarHandles and give our core reflection
On 2/01/2017 9:45 PM, Claes Redestad wrote:
On 12/31/2016 12:45 AM, David Holmes wrote:
I'll let you think about it so more. I'll be back in the office on
Tuesday :)
After giving it some thought I think it's better to just document the need
for some hygiene in the field declaration:
http://cr
On 2017-01-02 18:02, Chris Hegarty wrote:
On 2 Jan 2017, at 11:45, Claes Redestad wrote:
On 12/31/2016 12:45 AM, David Holmes wrote:
I'll let you think about it so more. I'll be back in the office on Tuesday :)
After giving it some thought I think it's better to just document the need
fo
> On 2 Jan 2017, at 11:45, Claes Redestad wrote:
>
> On 12/31/2016 12:45 AM, David Holmes wrote:
>> I'll let you think about it so more. I'll be back in the office on Tuesday :)
>
> After giving it some thought I think it's better to just document the need
> for some hygiene in the field declar
On 12/31/2016 12:45 AM, David Holmes wrote:
I'll let you think about it so more. I'll be back in the office on
Tuesday :)
After giving it some thought I think it's better to just document the need
for some hygiene in the field declaration:
http://cr.openjdk.java.net/~redestad/8172048/webrev.02
Hi Peter,
agreed, it appears this assert could be replaced by a test - similar to
what was already
done for VarHandle.AccessMode[1] - which might increase robustness of
early use of
VarHandles and give our core reflection libraries the freedom to use
VarHandles.
Paul?
/Claes
[1] https://
On 31/12/2016 12:50 AM, Claes Redestad wrote:
Hi David,
On 2016-12-30 02:10, David Holmes wrote:
Hi Claes,
On 28/12/2016 12:04 AM, Claes Redestad wrote:
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
l
Hi David,
On 2016-12-30 02:10, David Holmes wrote:
Hi Claes,
On 28/12/2016 12:04 AM, Claes Redestad wrote:
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
lead to hard to diagnose bootstrap cycles (since
Hi Claes,
On 28/12/2016 12:04 AM, Claes Redestad wrote:
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
lead to hard to diagnose bootstrap cycles (since VarHandles has to do
doPrivileged calls during setup
Hi Claes,
A nice find! This is certainly a straightforward and low-risk fix for
breaking the initialization cycle problem with JDK-8062389.
Related to VarHandles, the call trace of the initialization cycle also
includes the following part of code in VarHandle:
AccessMode(final Stri
Hi,
since java.util.concurrent.AtomicReference was changed to use a
VarHandle internally, using it from within the security libraries can
lead to hard to diagnose bootstrap cycles (since VarHandles has to do
doPrivileged calls during setup). The need to initialize VarHandles is
also cause for a s
11 matches
Mail list logo
