Hi Brandon. I think the idea of dynamic SimObjects is a bit broken, at least with how things are designed now. There's the issue you mentioned, but then also the various phases of SimObject setup (init, regStats, loadState, etc.) aren't going to happen like they're supposed to, or at least when they're supposed to. Also objects that count on the python config to set up various properties like finding a parent system object (for instance) can't work when the python hierarchy is gone or at least inaccessible.
I think the "correct" way to do what you're trying to do would be to make the Process object not a SimObject at all, and to have a new SimObject which reflects the executable/binary you're loading to create a Process. That object would be known and fixed at config time, and it could result in 0-n Processes during simulation. That would also be a decent collecting point for serialization during checkpoint creation/loading (which dynamic SimObjects would likely also break). Gabe On Tue, Apr 30, 2019 at 9:00 AM Potter, Brandon <[email protected]> wrote: > Hi all, > > I merged changeset 2367198921 which added support for dynamically creating > Process objects during simulation. This feature is needed to allow > applications to call the clone system call (which serves to fork a process) > in the middle of simulation. > > Inadvertently, this creates a problem with dynamically creating SimObjects > which might be new to the simulator. > > The Process class uses a SimObject class as a base class. Both Process and > SimObject use Params (normally set by Python) to initialize themselves. > During clone, I duplicate the ProcessParams and pass them into the Process > constructor while dynamically allocating an instance of a Process object. > After I initialized ProcessParams and use them to create the new Process > object, I deleted them (not wanting to leak memory). However, the SimObject > class caches a const pointer to Params which can cause memory corruption > after the free if the pointer is accessed. (Jason points this out with > https://gem5-review.googlesource.com/c/public/gem5/+/18068.) > > The issue can be avoided by removing the cached Params pointer and instead > only storing the relevant fields which are accessed by the class. However, > SimObject establishes an accessor API for Params which other classes have > also implemented. The derived classes essentially implement the same method > with a cast to convert the Params to the derived class type. > > This leaves me in a bit of a bind since I am not sure what the established > design principle is regarding Params. Conceptually, there is no reason why > we could not store the relevant fields which each of the Params types > provide in the respective classes. However, it is a fairly extensive change > which could be contentious. > > Does anyone have a suggestion on how to go about resolving the issue? > > Regards, > Brandon > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
