[lworld+vector] RFR: 8314628: [lworld+vector] validation regression fixes and cleanups. [v2]

[Jatin Bhateja]

On Wed, 23 Aug 2023 01:42:34 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> I am planning to use these symbol definitions in Max species support, estimation of multifield bundle size for max species cannot be just done based on MaxVectorSize, e.g., both LongMaxMask and ByteMaxMask will encapsulate VectorPayloadMFMaxZ which will hold @multifield(-1) annotated boolean mfield.
>> 
>> In order to determine the bundle size, we need to resort to VM symbol name comparison during field parsing, payload class names should also be different for Byte and Long max species mask e.g. VectorPayloadMFMaxZL and VectorPayLoadMFMaxZB. Bundle size for Long should be 8 while for Byte should be 64 for 512-bit MaxVectorSize.
>
> I also spent some time looking at this part. It's true that we have to distingunish the max lanecount for different types of VectorMask. As for this part, maybe we could also extend the `MultiField` annotation by adding another variable denotaing the type info like `esize/scale`. And calculate the right lanecount based on the `MaxVectorSize` and `esize/scale` when parsing classfile. WDYT?

Even if we extend @multifield annotation to pass an explicit lane size, we still need to create separate Java classes for different Max species mask payloads e.g. VectorPayloadMaxLZ, VectorPayloadMaxBZ. In usual scenario field type is known to parser and sufficient to determine its size, only bundle width is passed explicitly. Its only for MaxSpecies where bundle size is dependent on MaxVectorSize we may need to do a symbol comparison, but your suggestion looks good and may save costly symbol lookup.

-------------

PR Review Comment: https://git.openjdk.org/valhalla/pull/909#discussion_r1303813621