Hi Yasumasa,
I think it should be "[@]". Angle brackets are used to
indicate non-literal values (ones to be replaced by something the user
chooses), but the '@' is a literal value, so should not be enclosed in
the angle brackets.
Also one minor thing. You ended up duplicating the //:
60
On 7/07/2019 6:48 pm, Erik Osterlund wrote:
Yeah that switch statement code and yet another plain non-volatile load/store
loop looks like complete nonsense unfortunately. It should at least use
Atomic::load/store.
Fortunately, on x86_64, I believe it will in practice yield word atomic copying
Erik,
Thanks for chiming in on this thread...
On 7/7/19 4:48 AM, Erik Osterlund wrote:
Yeah that switch statement code and yet another plain non-volatile load/store
loop looks like complete nonsense unfortunately. It should at least use
Atomic::load/store.
Fortunately, on x86_64, I believe
On 2019/07/07 22:07, Daniel D. Daugherty wrote:
On 7/6/19 8:55 PM, Yasumasa Suenaga wrote:
Hi Chris,
Thank you for your advise.
I uploaded new webrev. How about this?
http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.04/
I replaced "server" to "host" as you said.
Other comments from y
On 7/6/19 8:55 PM, Yasumasa Suenaga wrote:
Hi Chris,
Thank you for your advise.
I uploaded new webrev. How about this?
http://cr.openjdk.java.net/~ysuenaga/JDK-8209790/webrev.04/
I replaced "server" to "host" as you said.
Other comments from you also have been fixed in it.
For example, `jhs
Thanks for the re-review!
Dan
On 7/7/19 5:16 AM, serguei.spit...@oracle.com wrote:
Hi Dan,
The update looks good to me.
Thanks,
Serguei
On 7/5/19 13:24, Daniel D. Daugherty wrote:
Greetings,
Here's the new webrev URLs after CR0:
Full:
http://cr.openjdk.java.net/~dcubed/8227117-webrev/1
Hi Dan,
The update looks good to me.
Thanks,
Serguei
On 7/5/19 13:24, Daniel D. Daugherty wrote:
Greetings,
Here's the new webrev URLs after CR0:
Full:
http://cr.openjdk.java.net/~dcubed/8227117-webrev/1_for_jdk14.full/
Inc:
http://cr.openjdk.java.net/~dcubed/8227117-webrev/1_for_jdk14.i
Yeah that switch statement code and yet another plain non-volatile load/store
loop looks like complete nonsense unfortunately. It should at least use
Atomic::load/store.
Fortunately, on x86_64, I believe it will in practice yield word atomic copying
anyway by chance. But it should be fixed anyw
