On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 23:15:44 GMT, John R Rose wrote:
>> Yep, to distinguish access and the encapsulated read-modify-write atomicity,
>> I decided to avoid using "atomic"/"non-atomic" altogether - now it is just
>> "make no atomicity guarantee"
>
> Not sure this is relevant, but isn't "opaque" a
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:00:31 GMT, Chen Liang wrote:
>> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>>
>>> 279: * read write access modes for all {@code T}. On 32-bit platforms,
>>> access modes
>>> 280: * {@code get} and {@code set} for {@code long}, {@code d
On 11 Jul 2025, at 6:19, Chen Liang wrote:
> On Fri, 11 Jul 2025 13:05:09 GMT, Raffaello Giulietti
> wrote:
>
>>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4311:
>>>
4309: * access modes {@code get} and {@code set} for {@code
long}, {@code
4310
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Thu, 17 Jul 2025 18:28:04 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the improved specification from
> `MemoryLayout::varHandl
On Thu, 17 Jul 2025 18:18:21 GMT, Maurizio Cimadamore
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> avoid "non-atomic"
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>
>> 279: * re
On Thu, 17 Jul 2025 17:57:16 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Wed, 16 Jul 2025 09:28:28 GMT, Raffaello Giulietti
wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> "may be non-atomic"
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>
>> 279: * r
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the improved specification from
> `MemoryLayout::varHandl
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 19:02:31 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 17:45:01 GMT, Paul Sandoz wrote:
>> Chen Liang has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Correct term is atomic, not word tearing
>
> src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 281:
>
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the improved specification from
> `MemoryLayout::varHandl
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 14:27:21 GMT, Chen Liang wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borrowing
On Fri, 11 Jul 2025 13:17:04 GMT, Chen Liang wrote:
>> Right, "word tearing" and "non-atomic access" are different notions.
>
> True, word tearing is racing a single memory location. Good that we
> discovered another spec bug and could fix it in time for 25.
I have changed to use the correct te
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the improved specification from
> `MemoryLayout::varHandl
On Fri, 11 Jul 2025 13:05:09 GMT, Raffaello Giulietti
wrote:
>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4311:
>>
>>> 4309: * access modes {@code get} and {@code set} for {@code long},
>>> {@code
>>> 4310: * double} are supported but might lead to
On Fri, 11 Jul 2025 08:19:43 GMT, Aleksey Shipilev wrote:
>> On 32 bit platforms, when an access to long/double is aligned, it is
>> supported but not atomic. The original wording in
>> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
>> all. We can fix that by borr
On Thu, 10 Jul 2025 23:40:15 GMT, Chen Liang wrote:
> On 32 bit platforms, when an access to long/double is aligned, it is
> supported but not atomic. The original wording in
> `MethodHandles::byteBufferViewVarHandle` sounds as if it is not supported at
> all. We can fix that by borrowing the
27 matches
Mail list logo
