Skip to content

Conversation

@LiangliangSui
Copy link
Contributor

To reduce the complexity of the ClassResolver class, we mainly do the following two things:

  1. Move ClassId related responsibilities into ClassIdAllocator class.

  2. Move registeredId2ClassInfo into ExtRegistry static inner class since they are content related.

To reduce the complexity of the `ClassResolver` class, we
mainly do the following two things:

1. Move ClassId related responsibilities into ClassIdAllocator class.

2. Move `registeredId2ClassInfo` into `ExtRegistry` static inner
class since they are content related.

Signed-off-by: LiangliangSui <coolsui.coding@gmail.com>

new ClassInfo(null, null, null, null, false, null, null, BuiltinClassId.NO_CLASS_ID);
private final Fury fury;
private ClassInfo[] registeredId2ClassInfo = new ClassInfo[] {};
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

registeredId2ClassInfo is in the critical path, we'd better to keep it here instead of extRegistry, which incur another pointer indirection.

@chaokunyang
Copy link
Collaborator

Hi @LiangliangSui , thanks for this work. We're standardlizing Fury xlang serialization protocol in #1413 , which may change class resolver too, especially the class id part. Can we hold this until the xlang serialization protocol are merged, so we don't have to refactor ClassResolver again.

The type id is lift to the first-class concept in #1413, we do need to strealine it from class resolver.

@LiangliangSui
Copy link
Contributor Author

Ok, we keep this PR until the xlang serialization protocol is merged.

@LiangliangSui LiangliangSui closed this by deleting the head repository Apr 12, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants