> On 10 Feb 2016, at 02:03, Hans Boehm wrote:
>
> I found this a bit scary for naive readers:
>
> * The Java Language Specification permits operations to be executed in
> * orders different than are apparent in program source code, subject to
> * constraints arising, for example, from the use o
Hi Jeremy,
Sorry for the late reply. Catching after some distractions and being away.
> On 22 Jan 2016, at 19:03, Jeremy Manson wrote:
>
> Couple of thoughts:
> The Java Language Specification permits operations to be executed in orders
> different than are apparent in program source code, su
> On 26 Jan 2016, at 22:46, Brian Goetz wrote:
>
> I think that expectation is just out of date (if not outright mistaken.)
> Yes, j.l.i was originally called "java.dyn", but prior to shipping *7* we
> renamed it to j.l.i precisely because it had turned into a general
> customizable linkage
Hi Martin,
how about seeing j.l.i as a framework for lightweight reflection on the one
hand, and for method handle-based meta-programming on the other? That's clearly
usable beyond the domain of dynamic language implementation. Granted, the
latter remains an important application area, but ther
I think that expectation is just out of date (if not outright
mistaken.) Yes, j.l.i was originally called "java.dyn", but prior to
shipping *7* we renamed it to j.l.i precisely because it had turned into
a general customizable linkage mechanism that was usable far beyond
dynamic languages. (To
There's a big "expectations" effect here. j.l.invoke is "supposed to
be" for making dynamic languages less slow, not for making low-level,
ultra-non-dynamic operations faster. Asking the Unsafe users of the
world to switch to dynamic VarHandle is like asking C programmers to
rewrite their code in
Hi
Many thanks for the feedback so far.
Some high-level responses:
1) I don’t think there is much we can do right now to reduce the verbosity of
reflective lookup. We have discussed this at least once before in the past. We
need field literals, as mentioned in the JEP, to really knock this on
This is my first attempt to understand java.lang.invoke. It seems
like a new alien world, non-java-like. I'll need to rebuild my
internal performance model of java code, perhaps by staring at jit
compiled code.
I expect new APIs for atomic variable access to appear in
j.u.c.atomic, not j.l.invok
Hi Doug,
I somehow missed your reply and just now noticed it after Martin's last
email quoted it -- thanks for elaborating.
The new name is required because opaque is only "like" C++
> memory_order_relaxed.
> See the jmm-dev list discussions last year for details, but annoyingly,
> Java normal va
On Fri, Jan 22, 2016 at 5:23 AM, Doug Lea wrote:
> On 01/22/2016 04:51 AM, Andrew Haley wrote:
>>
>> On 22/01/16 00:01, Vitaly Davidovich wrote:
>>>
>>> I think the get/setOpaque methods need a bit more explanation ("opaque"
>>> is
>>> an odd naming choice, IMO). Specifically, it says the operati
The VarHandle API isn't ergonomic like Unsafe; this being for power
users is irrelevant to the ergonomics of the API. Instead, it's fairly
verbose with setup ceremony. Now, I personally don't mind that too
much and more interested in the features it provides but I'm not
surprised by David's
Agreed; it's a building block, not an assembled piece.
On Friday, January 22, 2016, Brian Goetz wrote:
>
> The VarHandle API isn't ergonomic like Unsafe; this being for power users
>> is irrelevant to the ergonomics of the API. Instead, it's fairly verbose
>> with setup ceremony. Now, I persona
+1, good stuff Aleksey (I had actually seen chatter about this change on
one of these openjdk lists, but people have already moved away from the
field updaters), except every time I think about final instance fields not
being treated as constants I get sad :). The other wrinkle is the "am I
lucky
On 01/22/2016 07:57 AM, Aleksey Shipilev wrote:
On 01/22/2016 04:54 PM, David M. Lloyd wrote:
The costs are both performance and memory overhead. The
Atomic*FieldUpdaters are good for memory usage and reasonably usable,
but suffer from performance problems and generics issues.
Hopefully, not
The costs are both performance and memory overhead. The
Atomic*FieldUpdaters are good for memory usage and reasonably usable,
but suffer from performance problems and generics issues. The "regular"
Atomic* classes have good usability (including with generic types) and
generally very good perf
So in this regard, VH ought to be better since it will have performance
like Unsafe (rather than field updaters - is that accurate by the way? Is
VH on par with Unsafe for issuing atomic ops?) and not have the memory
bloat of the instance atomic classes. Generics is a non-issue for VH.
I do agree
On 01/22/2016 04:54 PM, David M. Lloyd wrote:
> The costs are both performance and memory overhead. The
> Atomic*FieldUpdaters are good for memory usage and reasonably usable,
> but suffer from performance problems and generics issues.
Hopefully, not anymore:
http://shipilev.net/blog/2015/faste
On 01/22/2016 07:29 AM, Vitaly Davidovich wrote:
Experts need control more than anything else. This is not to say they'll
be happy with a subpar API but control typically means lots of details so
there's a limit on how abstracted the API can be. As mentioned, given the
API provides low level co
Which existing Atomic* classes? I take it you mean the field updaters and
not AtomicInteger and friends. The biggest issue with field updaters is
their performance, for me. I take it you mean something else by "costs"
though? Having to specify the target (field) as a string is annoying, and I
do
On Friday, January 22, 2016, David M. Lloyd wrote:
> On 01/21/2016 07:32 PM, Brian Goetz wrote:
>
>>
>> I am baffled as to how the original language syntax proposal of using
>>> some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two
>>> new bytecodes was considered unacceptable; lo
On 01/22/2016 04:51 AM, Andrew Haley wrote:
On 22/01/16 00:01, Vitaly Davidovich wrote:
I think the get/setOpaque methods need a bit more explanation ("opaque" is
an odd naming choice, IMO). Specifically, it says the operations are done
in program order but have no effect on inter-thread orderi
On Friday, January 22, 2016, Aleksey Shipilev
wrote:
> On 01/22/2016 03:08 PM, Vitaly Davidovich wrote:
> > The VarHandle API isn't ergonomic like Unsafe; this being for power users
> > is irrelevant to the ergonomics of the API. Instead, it's fairly verbose
> > with setup ceremony. Now, I pers
On 01/21/2016 07:32 PM, Brian Goetz wrote:
I am baffled as to how the original language syntax proposal of using
some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two
new bytecodes was considered unacceptable; looking at this API, I know
that none of the aforementioned metrics w
On 01/22/2016 03:08 PM, Vitaly Davidovich wrote:
> The VarHandle API isn't ergonomic like Unsafe; this being for power users
> is irrelevant to the ergonomics of the API. Instead, it's fairly verbose
> with setup ceremony. Now, I personally don't mind that too much and more
> interested in the fe
On Friday, January 22, 2016, Andrew Haley wrote:
> On 01/22/2016 11:15 AM, Vitaly Davidovich wrote:
>
> > I'm guessing opaque is compiler only fence because a method that a
> > compiler doesn't inline (as an example) is considered "opaque" to
> > the compiler and serves like a fence. Perhaps tha
On 01/22/2016 11:15 AM, Vitaly Davidovich wrote:
> I'm guessing opaque is compiler only fence because a method that a
> compiler doesn't inline (as an example) is considered "opaque" to
> the compiler and serves like a fence. Perhaps that's how opaque
> ended up here. At any rate, I think it's a
On Thursday, January 21, 2016, Brian Goetz wrote:
>
> I am baffled as to how the original language syntax proposal of using some
>> trick like "xx.volatile.imaginaryMethod()" plus maybe one or two new
>> bytecodes was considered unacceptable; looking at this API, I know that
>> none of the aforem
On Friday, January 22, 2016, Andrew Haley wrote:
> On 22/01/16 00:01, Vitaly Davidovich wrote:
> > I think the get/setOpaque methods need a bit more explanation ("opaque"
> is
> > an odd naming choice, IMO). Specifically, it says the operations are
> done
> > in program order but have no effect
On 22/01/16 00:01, Vitaly Davidovich wrote:
> I think the get/setOpaque methods need a bit more explanation ("opaque" is
> an odd naming choice, IMO). Specifically, it says the operations are done
> in program order but have no effect on inter-thread ordering/visibility.
> Is this spec verbiage fo
Hi Paul,
I found a typo (which was probably caused by unconscious influence from
jigsaw ;-). Search for "Java Memory Module"...
Regards, Peter
On 01/21/2016 11:42 PM, Paul Sandoz wrote:
Hi
This is a request to review the VarHandles API. The code reviews and pushes
will occur separately, an
I am baffled as to how the original language syntax proposal of using
some trick like "xx.volatile.imaginaryMethod()" plus maybe one or two
new bytecodes was considered unacceptable; looking at this API, I know
that none of the aforementioned metrics were considered as acceptance
criteria. H
I think the get/setOpaque methods need a bit more explanation ("opaque" is
an odd naming choice, IMO). Specifically, it says the operations are done
in program order but have no effect on inter-thread ordering/visibility.
Is this spec verbiage for a full compiler-only fence?
On Thursday, January
On 01/21/2016 04:42 PM, Paul Sandoz wrote:
Hi
This is a request to review the VarHandles API. The code reviews and pushes
will occur separately, and flow through the hs-comp repo, most likely from the
bottom up first with Unsafe changes.
The specdiff can be found here:
http://cr.openjdk.
33 matches
Mail list logo
