RFR: 8299576: Reimplement java.io.Bits using VarHandle access [v5]

Uwe Schindler uschindler at apache.org
Thu Jan 5 12:37:33 UTC 2023


Hi,

I answered on the PR on github. The documentation is misleading:

    The copypasted snippet above is misleading, you need to read the
    whole statement, so an IllegalStateException can only happen for
    unaligned access on access modes other than get/set (so volatile or
    opaque reads): "If access is misaligned then access for
    anything*other than the get and set access modes*will result in an
    IllegalStateException.", the sentence you posted is about if it is
    atomic or not. It just says that on 32 bits, long/double are not
    atomic for normal set/get.

    P.S.: We definitely know that it works on 32 bit, the whole code of
    Lucene is full of those VarHandles :-)

And no, it doe snot mean "get-and-set". Read the whole text, it is 
definitely correct, but if you don't read everything it may mislead you. 
So it can be improved.

Uwe

Am 05.01.2023 um 13:31 schrieb Michael Kuhlmann:
> The more I think about it, the clearer is that the first line of the 
> Javadoc is contrary to the other lines:
>
> On 1/5/23 12:59, Michael Kuhlmann wrote:
>> * read write access modes for all T, with the exception of access 
>> modes get and set for long and double on 32-bit platforms.
>
> So all read write modes will work, just if it's long or double then it 
> won't work for get and for set access mode. (Or is getAndSet meant? 
> But it's not called so, it's "get and set", so two access modes, or 
> what?)
>
> Then the following lines state that even harder access modes will work 
> also for long and double.
>
> So I think this should be labeled as "getAndSet" or at least 
> "get-and-set" access mode. Currently it's very confusing.

-- 
Uwe Schindler
uschindler at apache.org  
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230105/1cf1e918/attachment.htm>


More information about the core-libs-dev mailing list