Job Length (4 Frame Max?) & Job System Status

Hi, to begin I would like to thank Unity for how supportive they have been about Beta features! You guys are awesome. I just have a few questions about the new job system.

To begin I’m running 2018.2.0b4 on Windows 10 and interested in developing for Linux, Mac, and Windows.

First, I just transitioned my personal job system to the new Beta system and performance-wise it is working really great. I have some really computationally hard problems being solved in the jobs and I have “Manager” structs for each job type that contains the Job, Handle, and a callback Action. I have a queue for each Manager type and in LateUpdate() I check to see if the the job at the front of each queue IsCompleted is true. If it is, I call Complete() to initiate cleanup call the callback function and Dispose() for each NativeArray. It looks something like this:

private void LateUpdate() {
    if (firstJobQueue.Count > 0 && firstJobQueue.Peek().handle.IsCompleted) {
        FirstManager helper = firstJobQueue.Deque();
        helper.handle.Complete();
        helper.callback(helper.job.someNativeArray.ToArray());
        helper.job.someNativeArray.Dispose();
    }
    if (secondJobQueue.Count > 0 ...) {
        ...
    }
    ... (for each queue)
}

I only pop the first Manager of the queue each frame because the callbacks are not themselves very fast. Regardless, the jobs sometimes last more than 4 frames anyway and I don’t want their computation time to affect the rendering performance at all. However, I am getting the following warning:

Internal: JobTempAlloc has allocations that are more than 4 frames old - this is not allowed and likely a leak

My question is I know that I am fully disposing the NativeArrays once the job is done (they are initialized with Allocator.Persistant). Does it really matter if they last more than 4 frames? Does this mean that I am actually leaking memory despite properly handling the NativeArrays properly? Will this affect anything when I go to build the projects? Is not is there any way to suppress these errors as they do not actually apply to my case?

My last question is about the NativeList, NativeQueue, and the other managed/unmanaged memory structures. I found the collections.zip for them but they require you to allow “unsafe” code. I would not like to pursue this route since this seems a bit too experimental to me and not sure how this affects builds but they would be really useful in my projects. Could I get an estimate to when these structures will be added to an official Beta version to start testing them out? Thank you so much :slight_smile: and sorry about all of the questions.

Just the last question, I think unsafe is definitely not going away from that assembly’s requirement even in the full release seeing that it interacts with the memory natively. Also Unity.Mathematics/Jobs/Entities and friends are all unsafe. By the way your whole game is not required to be unsafe, just those libraries.

3499931--278963--Screenshot 2018-05-17 13.58.41.png

I would like to piggyback your question as well, as what would be the suitable job for Allocation.TempJob? In what situation that I can ensure something is more than one scope but less than 4 frames? For now I can find places to use both .Temp and .Persistent but not .TempJob at all.

For some place that I use .Persistent, actually I am quite confident that it might be less than 4 frames but what if the device is a bit slow and it takes 5 frames? Out of this kind of fear I have never got a chance to use .TempJob and wondering why they added this.

@Elveskevtar

Would it be possible to provide a github with the manager? I am curious to see the implementation and play around. Sadly i cannot help with your question :S

Thank you for this! Didn’t even realize you could mark a single library as unsafe!

In terms of your question, I am not allocating the memory that I am using with Allocation.TempJob, I am using Persistent. This leads me to believe that the IJobs themselves are being stored in Native memory with Allocation.TempJob because I never use this allocator. If this is true I guess my question for the devs is similar to what you are saying. There are definitely cases where my jobs run for a tiny bit more than 4 frames (I have beefy specs it’s just a lot of computation) and would it be possible to set the allocator of the Jobs themselves?

I’ll make a new repo for it later today!

I’ve been messing around with it and I don’t believe it’s actually leaking any memory since it’s only giving me warnings for the few times my job takes more than four frames. It would be nice to suppress these errors though.

Here, actually the majority of the system is consolidated into my TerrainGenerator script. Let me know your thoughts! The jobs themselves are a WIP but the system is basically where I want it to be.

I am currently using NativeArrays but NativeLists make much more sense for my application. Also, you might already be aware but all contents of the Native memory must be blittable. Kind of annoying but probably a lot safer.

3500317–279018–TerrainGenerator.cs (4.69 KB)

thanks man I will look into it. If i have anything to contribute ill let you know