RFR: 8315716: RISC-V: implement ChaCha20 intrinsic
Robbin Ehn
rehn at openjdk.org
Wed Sep 27 13:49:13 UTC 2023
On Tue, 26 Sep 2023 17:38:26 GMT, Hamlin Li <mli at openjdk.org> wrote:
>> It's the paragraph above:
>>
>> The tail elements during a vector instruction’s execution are the elements past the current vector length setting specified in vl.
>>
>>
>> This means they are outside of your working set (body).
>>
>>
>> When a set is marked agnostic, the corresponding set of destination elements in any vector destination operand
>> can either retain the value they previously held, or are overwritten with 1s. Within a single vector instruction, each
>> destination element can be either left undisturbed or overwritten with 1s, in any combination, and the pattern of
>> undisturbed or overwritten with 1s is not required to be deterministic when the instruction is executed with the same
>> inputs.
>>
>>
>> Maybe this can't happen here since you work with such nice size.
>> But the arrays result and startState will be initialized to zero when allocated.
>> We don't want anything changing bytes which the VM didn't write to and we must be sure never to write outside of these.
>>
>> So tail is what comes after you data, in our case that will be Java heap, so we must always be sure only to write to the body.
>>
>> Did that make sense?
>
> Thanks for discussion. Yes, I see your point.
> What I mean above is that the java heap can only be touched when store back to memory, but store `only access memory or raise exceptions for active elements.`, that seems mean that a vectore operation might touch tail elements in vector group register, but a vector store will not touch the memory corresponding to the tail elements.
> Am I understanding the spec correctly?
I don't see that the specs guarantees that under no circumstance tail memory will not be touched.
So I don't know, for now it's better to be safe than sorry.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/15899#discussion_r1338640884
More information about the hotspot-dev
mailing list