[YANGTOOLS-1503] Disconnect NamespaceStmtCtx from Current and StmtContext Created: 06/Apr/23  Updated: 06/Apr/23  Resolved: 06/Apr/23

Status: Resolved
Project: yangtools
Component/s: parser
Affects Version/s: None
Fix Version/s: None

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

Issue Links:
Blocks
is blocked by YANGTOOLS-1497 Improve NamespaceBehaviour/NamespaceS... Resolved
Epic Link: Parser Performance

 Description   

The two user-facing contexts expose namespace access, each of which requires resolving a NamespaceAccess – which ends up going to BuildGlobalContext.

This is currently dictated by legacy class hierarchy and APIs, but we should be able to disconnect these three and passing around a NamespaceCtx:

 

interface NamespaceCtx {
 
    <K, V> @Nullable Map<K, V> namespace(CommonStmtCtx stmt, ParserNamespace<K, V> namespace);

    <K, V> @Nullable V namespaceItem(CommonStmtCtx stmt, ParserNamespace<K, V> namespace, K key);

    <K, V> @Nullable Map<K, V> localNamespacePortion(CommonStmtCtx stmt, ParserNamespace<K, V> namespace);
}

to all methods which are allowed to access namespaces.

 

The reactor would implement this through BuildGlobalContext, which would mean that AbstractStorageNode would not need accessNamespace(). There are two wrinkles:

  1. the need to cast stmt to ReactorStmtCtx – which is essentially fine
  2. the amount of API changes – which entails a lot of work

 

 Comments   
Comment by Robert Varga [ 06/Apr/23 ]

Okay, so after a quick prototype, this approach is not really feasible. The issue is not user-facing, but rather reactor-internal. Passing GlobalContext around would be VERY disrupive.

Another alternative would be disconnect ReactorStmtCtx from StmtContext (and others) and allocate them when we are going towards the user. That is also problematic due to three reasons:

  1. we have no control over retaining the object, i.e. a number of users end up storing the reference – that wrecks any attempt at reuse by itself, meaning increased GC pressure
  2. StmtContexts are stored in namespaces – which means AbstractNamespaceStorage would have to wrap/unwrap objects as well (and detect when it needs to do so), otherwise we would be end up increasing our memory footprint
  3. yang-parser-reactor itself needs to manipulate namespacse, which means wrapping/unwrapping would be even more awkward

Yet another alternative would be to store BuildGlobalContext in every node – but that is just a CPU/memory trade-off, and making the templating phase just as intensive. We may retry once YANGTOOLS-1207 is done, as that might give us a tad better tools.

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