Coroutines for low latency/zero gc software

And reading a decompiled code is reading an incorrect code in the first place. Decompilers don’t provide any guarantees they provide a correct code, they often produce incorrect results.

And this case is in fact a really easy one:

       0: aload_0
       1: instanceof    #11                 // class Test1Kt$test2$1
       4: ifeq          36
          ...
      36: new           #11                 // class Test1Kt$test2$1

Check if the continuation is of my type, if not, jump to 36 where my continuation is constructed.

But well, do as you like :slight_smile:

1 Like

Well you can see it in decompiled code too its just i assumed the continuation type is of your own type if you created it previously… i’m not sure why it would be of other type? like what would this method do with some other methods continuation… isnt its purpose to basically have the other half of the method after suspending statement?

so imo this almost never will be of different type, but yeah we are just speculating about everything at this point, a dev needs to comment or a deep dive is due

As said above, it will be of another type during the initial invocation. Caller passes its own continuation to the called function, so it could be resumed at a later time. You should see somewhere in the code that the above continuation is passed to delay(). This is how functions distinguish if they were invoked or resumed.

2 Likes

The current step of computation is in the label attribute.
Kotlin uses a different label for each suspension point (1, 2, 3, …).
If label == 0 the Continuation has not been started yet, else if label == -1 the continuation is terminated.

1 Like

It’s pretty simple to check if there are allocations or not, though. Take a heap dump, execute your loop with a suspend function inside twice, take a heap dump, look at the diff.
If you need to make sure that your program makes 0 allocations after the warm-up, you must have a way to verify that; so
you’d be able to use it to tell if coroutines make allocations or not. If they do, it’s likely you can’t change anything about that.

You do know that every time you take a heap dump it triggers a GC and only after whats left ends up in the dump…?

Not having allocations and not having leaks is very different.
Either way i’m going to properly dive into this later on. We will see how messy things are under the hood.

Yes there is a proper way to see allocations, heap dumps are not that…

OK, correction: instead of heap dumps, start tracking allocations. Yourkit can do that

What technique do you use to verify your program doesn’t make allocations?

This works if you use EpsilonGC.
But I suggest async-profiler, it is a nice tool to measure that.

There are tools that track allocations without any GC, i dont remember like this but it was standard command line stuff that essentially looked at TLAB, how full your TLAB is… (thats the memory each thread has) and it would track in which function does TLAB change… that is your allocation.