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