Performance bottleneck of multi-threaded conversion jimple

[zhangziqiang1]

trafficstars

https://github.com/soot-oss/soot/blob/8db5d69f2a53b6e7e12d161a7713c4c71ba6cbf2/src/main/java/soot/Scene.java#L1365

When I use multi-threading to improve the performance of jimple, I found that the performance bottleneck is reading FastHierarchy, FastHierarchy will not change during initialization, and the locking here is too rough. I consider to initialize activeFastHierarchy in advance before converting jimple, so that locking is not needed, because multi-threaded reading map can give full play to the performance of the machine. Not sure if I'm thinking correctly. looking forward to your reply!

[zhangziqiang1]

@StevenArzt

[StevenArzt]

You can try to implement your suggested changes and open a merge request. Be careful that loading Jimple bodies may introduce new (phantom) classes and methods, which automatically invalidates / releases the hierarchy. You would need to find a solution for these updates. I guess you can ignore most changes, because phantom classes are handled separately in the hierarchy anyway.

[zhangziqiang1]

I got you. However, the FastHierarchy object does not see that it will change during the loading of jimple. I see that the data has been determined during initialization.

[StevenArzt]

Have a look at Scene.modifyHierarchy(), which simply deletes the entire hierarchy from the Scene whenever a class is added.