On Wed, Mar 27, 2024 at 09:43:48PM +0000, Liam McGillivray via Digitalmars-d-learn wrote: [...]
> ```
>     ~this() {
>         this.alive = false;
>         if (this.map !is null) this.map.removeUnit(this);
>         if (this.faction !is null) this.faction.removeUnit(this);
>         if (this.currentTile !is null) this.currentTile.occupant = null;
>     }
> ```
[...]

What's the definition of this.map, this.faction, and this.currentTile?

If any of them are class objects, this would be the cause of your problem.  Basically, when the dtor runs, there is no guarantee that any referenced classed objects haven't already been collected by the GC. So if you try to access them, it will crash with an invalid memory access.

In general, it's a bad idea to do anything that relies on the dtor being run in a particular order, because the GC can collect dead objects in any order.  It's also illegal to perform any GC memory-related operations inside a dtor (like allocate memory, free memory, etc.) because the GC is not reentrant.

If you need deterministic clean up of your objects, you should do it before the last reference to the object is deleted.


T

-- 
He who does not appreciate the beauty of language is not worthy to bemoan its flaws.

On Thu, Mar 28, 2024 at 03:56:10AM +0000, Liam McGillivray via Digitalmars-d-learn wrote: [...]
> I may be now starting to see why the use of a garbage collector is such a point of contention for D. Not being able to predict how the garbage collection process will happen seems like a major problem.

If you want it to be predictable, simply:

	import core.memory;
	GC.disable();
	... // insert your code here
	if (timeToCleanup()) {
		GC.collect();	// now you know exactly when this happens
	}

Of course, you'll have to know exactly how timeToCleanup() should decide when it's time to collect.  Simple possibilities are once every N units of time, once every N iterations of some main loop, etc..  Or use a profiler to decide.


> > As mentioned, GCs do not work this way -- you do not need to worry about cascading removal of anything.
> 
> Wanting to avoid the GC pauses that I hear about, I was trying to optimize object deletion so that the GC doesn't have to look for every object individually. It sounds like what I'm hearing is that I should just leave everything to the GC. While I can do this without really hurting the performance of my program (for now), I don't like this.

The whole point of a GC is that you leave everything up to it to clean up.  If you want to manage your own memory, don't use the GC. D does not force you to use it; you can import core.stdc.stdlib and use malloc/free to your heart's content.


> I hope that solving the unpredictable destruction pattern is a priority for the developers of the language. This problem in my program wouldn't be happening if either *all* of the objects had their destructors called or *none* of them did.

Unpredictable order of collection is an inherent property of GCs. It's not going away.  If you don't like it, use malloc/free instead. (Or write your own memory management scheme.)


> Anyway, I suppose I'll have to experiment with either manually destroying every object at the end of every unittest, or just leaving more to the GC.  Maybe I'll make a separate `die` function for the units, if you think it's a good idea.
[...]

I think you're approaching this from a totally wrong angle. (Which I sympathize with, having come from a C/C++ background myself.)  The whole point of having a GC is that you *don't* worry about when an object is collected.  You just allocate whatever you need, and let the GC worry about cleaning up after you. The more you let the GC do its job, the better it will be.

Now of course there are situations where you need deterministic destruction, such as freeing up system resources as soon as they're no longer needed (file descriptors, OS shared memory segments allocations, etc.). For these you would manage the memory manually (e.g. with a struct that implements reference counting or whatever is appropriate).

As far as performance is concerned, a GC actually has higher throughput than manually freeing objects, because in a fragmented heap situation, freeing objects immediately when they go out of use incurs a lot of random access RAM roundtrip costs, whereas a GC that scans memory for references can amortize some of this cost to a single period of time.

Now somebody coming from C/C++ would immediately cringe at the thought that a major GC collection might strike at the least opportune time. For that, I'd say:

(1) don't fret about it until it actually becomes a problem. I.e., your program is slow and/or has bad response times, and the profiler is pointing to GC collections as the cause. Then you optimize appropriately with the usual practices for GC optimization: preallocate before your main loop, avoid frequent allocations of small objects (prefer to use structs rather than classes), reuse previous allocations instead of allocating new memory when you know that an existing object is no longer used.  In D, you can also selectively allocate certain troublesome objects with malloc/free instead (mixing both types of allocations is perfectly fine in D; we are not Java where you're forced to use the GC no matter what).

(2) Use D's GC control mechanisms to exercise some control over when collections happen. By default, collections ONLY ever get triggered if you try to allocate something and the heap has run out of memory.  Ergo, if you don't allocate anything, GC collections are guaranteed not to happen.  Use GC.disable and GC.collect to control when collections happen.  In one of my projects, I got a 40% performance boost by using GC.disable and using my own schedule of GC.collect, because the profiler revealed that collections were happening too frequently.  The exact details how what to do will depend on your project, of course, but my point is, there are plenty of tools at your disposal to exercise some degree of control.

Or if (1) and (2) are not enough for your particular case, you can
always resort to the nuclear option: slap @nogc on main() and use
malloc/free to your heart's content. IME, however, this is very, very
rarely called for.  Generally a combination of (1) and (2) has been more
than adequate to fix my GC issues.


T

-- 
Computerese Irregular Verb Conjugation: I have preferences.  You have biases.  He/She has prejudices. -- Gene Wirchenko

On Thu, Mar 28, 2024 at 11:49:19PM +0000, Liam McGillivray via Digitalmars-d-learn wrote:
> On Thursday, 28 March 2024 at 04:46:27 UTC, H. S. Teoh wrote:
> > The whole point of a GC is that you leave everything up to it to clean up.  If you want to manage your own memory, don't use the GC. D does not force you to use it; you can import core.stdc.stdlib and use malloc/free to your heart's content.
> > 
> > Unpredictable order of collection is an inherent property of GCs. It's not going away.  If you don't like it, use malloc/free instead. (Or write your own memory management scheme.)
> 
> I disagree with this attitude on how the GC should work. Having to jump immediately from leaving everything behind for the GC to fully manual memory allocation whenever the GC becomes a problem is a problem, which gives legitimacy to the common complaint of D being "garbage-collected". It would be much better if the garbage collector could be there as a backup for when it's needed, while allowing the programmer to write code for object destruction when they want to optimize.

Take a look at the docs for core.memory.GC.  There *is* a method GC.free that you can use to manually deallocate GC-allocated memory if you so wish.  Keep in mind, though, that manually managing memory in this way invites memory-related errors. That's not something I recommend unless you're adamant about doing everything the manual way.


> > > Anyway, I suppose I'll have to experiment with either manually destroying every object at the end of every unittest, or just leaving more to the GC. Maybe I'll make a separate `die` function for the units, if you think it's a good idea.
> > 
> > I think you're approaching this from a totally wrong angle. (Which I sympathize with, having come from a C/C++ background myself.)  The whole point of having a GC is that you *don't* worry about when an object is collected.  You just allocate whatever you need, and let the GC worry about cleaning up after you. The more you let the GC do its job, the better it will be.
> 
> Now you're giving me conflicting advice. I was told that my current destructor functions aren't acceptable with the garbage collector, and you specifically tell me to leave things to the GC. But then I suggest that I "leave more to the GC" and move everything from the Unit destructor to a specialized `die` function that can be called instead of `destroy` whenever they must be removed from the game, which as far as I can see is the only way to achieve the desired game functionality while following your and Steve's advice and not having dangling references. But in response to that, you tell me "I think you're approaching this from the wrong angle". And then right after that, you *again* tell me to "just let the GC worry about cleaning up after you"? Even if I didn't call `destroy` at all during my program, as far as I can see, I would still need the `die` function mentioned to remove a unit on death.

I think you're conflating two separate concepts, and it would help to distinguish between them.  There's the lifetime of a memory-allocated object, which is how long an object remains in the part of the heap that's allocated to it.  It begins when you allocate the object with `new`, and ends with the GC finds that it's no longer referenced and collects it.

There's a different lifetime that you appear to be talking about: the logical lifetime of an in-game object (not to be confused with an "object" in the OO sense, though the two may overlap).  The (game) object gets created (comes into existence in the simulated game world) at a certain point in game time, until something in the game simulation decides that it should no longer exist (it got destroyed, replaced with another object, whatever). At that point, it should be removed from the game simulation, and that's probably also what you have in mind when you mentioned your "die" function.

And here's the important point: the two *do not need to coincide*. Here's a concrete example of what I mean. Suppose in your game there's some in-game mechanic that's creating N objects per M turns, and another mechanic that's destroying some of these objects every L turns.  If you map these creations/destructions with the object lifetime, you're looking at a *lot* of memory allocations and deallocations throughout the course of your game.  Memory allocations and deallocations can be costly; this can become a problem if you're talking about a large number of objects, or if they're being created/destroyed very rapidly (e.g., they are fragments flying out from explosions).  Since most of these objects are identical in type, one way of optimizing the code is to preallocate them: before starting your main loop, say you allocate an array of say, 100 objects. Or 1000 or 10000, however many you anticipate you'll need. These objects aren't actually in the game world yet; you're merely reserving the memory for them beforehand. Mark each of them with a "live"-ness flag that indicates whether or not they're actually in the game.  Then during your main loop, whenever you need to create a new object of that type, don't allocate memory for it; just find a non-live object in this array, set its fields to the right values, and mark it "live".  Now it's a object in the game.  When the object is destroyed in-game, don't deallocate it; instead, just set its "live" flag to false.  Now you can blast through hundreds and thousands of these objects without incurring the cost of allocating and deallocating them every time.  You also save on GC cost (there's nothing for the GC to collect, so it doesn't need to run at all).

Don't get confused by the "object" terminology; an in-game object is not necessarily the same thing as a class object in your program. In fact, sometimes it's advantageous to treat them as separate things.


[...]
> > As far as performance is concerned, a GC actually has higher throughput than manually freeing objects, because in a fragmented heap situation, freeing objects immediately when they go out of use incurs a lot of random access RAM roundtrip costs, whereas a GC that scans memory for references can amortize some of this cost to a single period of time.
> 
> By "manually freeing objects", do you mean through `destroy`? If so that's actually quite disappointing, as D is often described as a "systems programming language", and I thought it would be fun to do these optimizations of object destruction, even if I have the garbage collector as a backup for anything missed. Or did you mean with `malloc` and `free`?

By "manually freeing objects" I mean what you typically do when you're using malloc/free.

Note that in D, you *can* actually "manually manage" some objects this way by calling GC.free.  I don't recommend this, though. It's not how the GC is intended to be used, and it can lead to memory safety problems.  My advice remains the same: just let the GC do its job. Don't "optimize" prematurely.  Use a profiler to test your program and identify its real bottlenecks before embarking on these often needlessly complicated premature optimizations that may turn out to be completely unnecessary.


[...]
> Well, I suppose that's fine for when the GC problem is specifically over slowness. I'm quite new to D, so I don't really know what it means to "preallocate before your main loop". Is this a combination of using `static this` constructors and `malloc`? I haven't used `malloc` yet. I have tried making static constructors, but every time I've tried them, they caused an error to happen immediately after the program is launched.

I gave an example of preallocation above.  It's not specific to GC or malloc/free; it's a general principle of reducing the number of allocations inside your main loop. If you can reserve beforehand the memory you know you'll need later, it will generally perform better than if you keep allocating on-the-fly.  Allocation and deallocation (or GC collection) always come with a cost; so you want to avoid doing this inside a hot loop, like your main game loop (assuming it's running every frame -- otherwise it's a non-issue and you shouldn't worry about it). Allocating N objects beforehand and then gradually using them as needed, is always better than starting with 0 objects and allocating each one individually inside your hot loop.


[...]
> I suppose I can turn the `Tile` object into a struct, which I suppose will mean replacing all it's references (outside the map's `Tile[][] grid`) with pointers. I have thought about this before, since tiles are fundamentally associated with one particular map, but I chose objects mostly so I can easily pass around references to them.

The correct design will depend on how you're using them, so I can't give you a specific recommendation here.

If you're conscious of performance, however, I'd say avoid references where you can.  Since maps presumably will always exist while the game is going on, why bother with references at all?  Just use a struct to store the coordinates of the tile, and look it up in the map.  Or if you need to distinguish between tiles belonging to multiple simultaneous maps, then store a reference to the parent map along with the coordinates, then you'll be able to find the right Tile easily. This way your maps can just store an array of Tile structs (single allocation), instead of an array of Tile objects (M*N allocations for an M×N map).


> I've already been using structs for the stuff with a short lifespan.

Good.


[...]
> I want to ask about `@nogc`. Does it simply place restrictions on what I can do? Or does it change the meaning of certain lines? For example, does it mean that I can still create objects, but they will just keep piling up without being cleaned up?

@nogc does not change runtime behaviour. It's a static enforcement that prevents your code from doing anything that might trigger GC allocations at all. So using anything that will trigger a GC allocation, such as using `new` or appending to an array with `~`, will cause a compile error.  I don't recommend using it (a pretty substantial chunk of the language and stdlib will become unavailable to you), but if you absolutely, totally, 100% want to abstain from using the GC at all, @nogc is your ticket to ensure that you didn't accidentally do so. The compiler will enforce it at compile-time.


T

-- 
Music critic: "That's an imitation fugue!"

On Wed, Apr 03, 2024 at 09:57:00PM +0000, Liam McGillivray via Digitalmars-d-learn wrote:
> On Friday, 29 March 2024 at 01:18:22 UTC, H. S. Teoh wrote:
> > Take a look at the docs for core.memory.GC.  There *is* a method GC.free that you can use to manually deallocate GC-allocated memory if you so wish.  Keep in mind, though, that manually managing memory in this way invites memory-related errors. That's not something I recommend unless you're adamant about doing everything the manual way.
> 
> Was this function removed from the library? I don't see it in [the document](https://dlang.org/phobos/core_memory.html).

https://dlang.org/phobos/core_memory.html#.GC.free


> How is `GC.free` different from `destroy`?

GC.free is low-level. It does not invoke dtors.


[...]
> When you mention a "flag" to indicate whether they are "live", do you mean like a boolean member variable for the `Unit` object? Like `bool alive;`?

Yes.


> > My advice remains the same: just let the GC do its job. Don't "optimize" prematurely.  Use a profiler to test your program and identify its real bottlenecks before embarking on these often needlessly complicated premature optimizations that may turn out to be completely unnecessary.
> 
> Alright. I suppose that some of the optimization decisions I have made so far may have resulted in less readable code for little performance benefit.  Now I'm trying to worry less about optimization. Everything has been very fast so far.
> 
> I haven't used a profiler yet, but I may like to try it.

Never make any optimization decisions without a profiler. I learned the hard way that more often than not, I'm wrong about where my program's bottleneck is, and that I spend far too much time and effort "optimizing" things that don't need to be optimized, while totally missing optimizations where it really matters.  Life is too short to be wasted on optimizing things that don't really matter.  When it comes to optimizations, always profile, profile, profile!


[...]
> It's unlikely that I will have multiple maps running simultaneously, unless if I do the AI thing mentioned above. I've had a dilemma of passing around references to the tile object vs passing around the coordinates, as is mentioned in an earlier thread that I started. In what way do references slow down performance? Would passing around a pair of coordinates to functions be better?

It's not references themselves that slow things down; it's the likelihood that using reference types when you don't need to can lead to excessive GC allocations, which in turn causes longer GC pauses.  Well, excessive dereferencing can also reduce cache coherence, but if you're already at the level where this actually makes a difference, you don't my advice anymore. :-D

Generally, if a piece of data is transient and not expected to last very long (e.g., past the current frame), it probably should be a struct rather than a class.  There are exceptions, of course, but generally that's how I'd decide whether something should be a by-value type or a by-reference type.


T

-- 
"The number you have dialed is imaginary. Please rotate your phone 90 degrees and try again."