[MDSAL-746] Improve BitsTypeObject storage Created: 11/Apr/22  Updated: 09/Jan/24

Status: Confirmed
Project: mdsal
Component/s: Binding codegen
Affects Version/s: None
Fix Version/s: 14.0.0

Type: Improvement Priority: Medium
Reporter: Robert Varga Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: pt
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Blocks
is blocked by MDSAL-744 Map bits type to primitive boolean Resolved
is blocked by MDSAL-764 Refactor binding-model-api Confirmed
Relates
relates to YANGTOOLS-1426 Consider bits type storage In Progress
Epic Link: Evolve bits mapping

 Description   

Separate from MDSAL-743, which defines the headline term, let's improve how we storage the individual bits. With MDSAL-744 we promise to provide a boolean value. Most of the bits we encounter have a very limited number of possible bits, let's say there are three classes:

  • up to 32 bits, which should use an 'int' for storage
  • up to 64 bits, which should use a 'long' for storage
  • more than 64 bits, which should use an int[] for storage]

Specialize codegen to recognize these three classes and store the set bits in the appropriate storage class, providing the required methods on bit operations. This will drop storage requirements (when compared to MDSAL-743) by additional factor of 8, providing a 32x/64x improvement when compared to current Boolean storage.

 Comments   
Comment by Robert Varga [ 11/Apr/22 ]

YANGTOOLS-1426 proposes to make similar improvements on yang.data.api level. While mdsal is free to its own thing (because "codegen"!) it would be nice if we could share some of the solution space.

Comment by Robert Varga [ 10/Nov/22 ]

So we are in a bit of a pickle w.r.t. serialization, I think.

serialVersionUID is based on properties, but it really needs to reflect resulting class layout as well to be really accurate.

The problem is that the current patch does not change serial version, even when fields change from individual booleans to ints/whatever.

I am not sure what to about this: I think serialVersionUID needs to capture both the properties and the resulting layout (hence mdsal-binding-generator needs to know about these).

Lets punt this for the next release.

Comment by Robert Varga [ 10/Nov/22 ]

I think we should do this only after MDSAL-764, which will give us a proper structure for what kinds of things we want to generate. Once we have that, we will have a BitsTypeObjectArchetype, which can capture the layout vs. properties difference, thus communicating clearly what needs to be generated and how.

On java-api-generator side this also implies creating a BitsTypeObjectTemplate and pulling bits-related special-cases there.

Generated at Wed Feb 07 20:10:50 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.