Skip to content

Questions about Tai-e's APIs and implementations of callgraphs #175

@jjppp

Description

@jjppp

📝 Overall Description

API design

I currently noticed that CallGraph provides two different APIs with the same default implementation, CallGraph.getCalleesOfM() and CallGraph.getSuccsOf():

public Set<Method> getCalleesOfM(Method caller) {
return callSitesIn(caller)
.flatMap(cs -> getCalleesOf(cs).stream())
.collect(Collectors.toUnmodifiableSet());
}

public Set<Method> getSuccsOf(Method node) {
return callSitesIn(node)
.flatMap(cs -> getCalleesOf(cs).stream())
.collect(Collectors.toUnmodifiableSet());
}

The getSuccsOf seems straightforward to me, but the getCalleesOfM takes me a while to realize its meaning.
My question: Is this a deliberate design choice? What is the rationale behind this?

Mutable vs Immutable

The callgraphs seem to be mutable by design, i.e., by allowing adding nodes and edges to the callgraphs. This makes several callgraph related operations inefficient, such as querying the successors and predecessors of a node, where caching the results might be difficult.

However, many applications do not actually modify the callgraph (e.g., traversing the callgraphs when computing SCCs). Is there any chance that Tai-e will introduce ImmutableCallGraph or something like that?

🎯 Expected Behavior

Just out of curiosity

🐛 Current Behavior

Just out of curiosity

🔄 Reproducible Example

No response

⚙️ Tai-e Arguments

🔍 Click here to see Tai-e Options
{{The content of 'output/options.yml' file}}
🔍 Click here to see Tai-e Analysis Plan
{{The content of 'output/tai-e-plan.yml' file}}

📜 Tai-e Log

🔍 Click here to see Tai-e Log
{{The content of 'output/tai-e.log' file}}

ℹ️ Additional Information

No response

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions