Go's Concurrency Examples in Java 19

https://mccue.dev/pages/5-2-22-go-concurrency-in-java

by emccue • 4 years ago

151 114 4 years ago

time.Sleep(100 * time.Millisecond) could also be: <-time.After(100 * time.Millisecond) so that an imaginary timeout can be easily handled with a select.

emccue12• 4 years ago

True, but I didn't write any of the Go here. Somewhat out of my wheelhouse

nahuel0x2• 4 years ago

Be careful with time.After, if you select on time.After and another channel c, and c breaks the select, then the timer will not be deallocated until it expires. So if the select is on a loop you can easily leak memory. Another of the Go hidden gotchas.

marginalia_nu• 4 years ago

While there are use cases where lightweight threads are a benefit, I think a web crawler is pretty much the ideal case for async/await, given you are almost exclusively waiting. Although I must admit I don't really understand this example, why is the fetching being parallellized, like you typically want to add sleeps, even with a single thread you've got yourself a gatling gun that can DoS a website if you aren't careful.

There's also some optimizations that could be made. Instead of having

    synchronized (seen) {
        if (!seen.contains(u)) {
            seen.add(u);
            // ...
        }
    }

you can get rid of the synchronization with

    // seen = ConcurrentHashMap.newKeySet()
    
    if (seen.add(u)) {
        // ...
    }

vips7L2• 4 years ago

I was surprised by the lack of ConcurrentHashMap. Does Go not have an equivalent?

racingmars• 4 years ago

Go does have a concurrent map in the standard library, but the documentation recommends not using it unless you have specific access patterns that it's optimized for:

https://pkg.go.dev/sync#Map

You lose type safety when using it. I'm guessing with generics in 1.18 now, we'll see an updated generic version of sync.Map whenever a bunch of new collection types are added to the standard library that take advantage of generics.

idoubtit• 4 years ago

In Go, while it is possible to use a concurrent hash map, it's generally not recommended. In most cases, you should use a channel.

In one of my first Go programs, I used mutexes to avoid concurrent writes in a critical part. Then I moved the writing process into a goroutine that receives its input through a channel of size 1. In my case, the later code was easier to maintain and more performant than the former, mutex-based, code.

emccue12• 4 years ago

Yeah - ConcurrentHashMap makes the most sense. I left it off just because I thought it would be easier to see the parallel with the Go code.

ibraheemdev• 4 years ago

There is no way for your operating system to know exactly how much stack space a thread will need so it allocates an amount on the order of around a megabyte. You only have around a bakers dozen gigabytes of RAM, so you can only make give or take 10,000 threads.

That's not true at all. The megabyte(s) of stack space is virtual, spawning a thread only requires a few kilobytes of memory initially, and is a lot cheaper than many realize.

taspeotis• 4 years ago

It's also not true when ... you tell it how much you need. Windows lets you specify a stack size [1].

[1] https://docs.microsoft.com/en-us/windows/win32/api/processth...

maeln• 4 years ago

Fun fact, you can declare a stack size at compile time (something like `cl ... -stack:0x5000000,0x5000000 ...`) which let you create insane stack size so that you can fit your all your software in the stack. Useful when you don't want to had an allocator when making tiny tiny executable files :D

SemanticStrengh2• 4 years ago

The main cost of spawning a thread is simply the time it takes to spawn.

latch• 4 years ago

What are you trying to say? This sounds like a tautology to me.

EdwardDiego5• 4 years ago

In Java, it defaults to 1MB on platforms other than Windows.

I've seen people OOM themselves by setting the default thread stack size massively high - they had likely gotten confused with the args (they'd used -Xss when I think they meant -Xms) and given their threads 1GiB of stack each.

I can't speak to how Java manages stack size between itself and the OS though, I'm sure there's deep magic there.

emccue12• 4 years ago

Here is the part where I admit that I am an idiot and don't actually know.

All I do know is that in Java I cannot create this many threads and in the talks given about Project Loom this is given as the explanation as to why.

https://www.youtube.com/watch?v=EO9oMiL1fFo @ ~4:00

Is it maybe not the actual spawning but some "switch" that flips once you start using the thread?

I'll update the post or leave a comment with a correction once I understand exactly what you mean

vlovich1232• 4 years ago

With Fibers you can implement user-space switching between virtual threads. For example, if a thread is going into a top-level select, switch it to a small stack putting the original large stack into a pool. On wake resume switch back to a larger stack. That’s basically what Project Loom is doing I suspect.

hddqsb• 4 years ago

The explanation in the video is good, here is a transcription for convenience (emphasis added):

OpenJDK implements threads as thin wrappers around the OS thread [...] OS threads are expensive, by which I mean that we cannot have too many of them. Maybe a few thousand active ones, maybe ten thousand active ones, but that's about it. And the reason for that is that the OS doesn't know the various languages, and the most costly component of a thread is its stack, and the operating system doesn't know how the various languages it might support makes use of the stack. So it must address the worst case and allocate a very large stack. It's usually on a megabyte scale. And even though we use virtual memory and not all of it is committed to physical memory, once we touch a page it becomes committed – it can't be uncommitted again because the OS doesn't know how the stack is used. And in any event, all the operations are done at a page granularity which is 4k, it's also not that small.

There may also be arbitrary OS-specific limits. For example on Linux there is system-wide limit on the number of threads, controlled by /proc/sys/kernel/threads-max (docs: https://www.kernel.org/doc/html/latest/admin-guide/sysctl/ke..., see also: https://stackoverflow.com/a/8849114). On my system it's ~60,000 (with 8G RAM).

torginus• 4 years ago

But does Loom reclaim allocated stack space once the thread's stack shrinks?

Skinney4• 4 years ago

I believe so, yes.

raducu• 4 years ago

But does Loom reclaim allocated stack space once the thread's stack shrinks?

Could you elaborate why you asked this? Is it because it's not done already? I'm genuinely curious.

freakynit• 4 years ago

Does GO even makes sense after Java's project loom and graalvm?

EdwardDiego5• 4 years ago

Graalvm takes some special effort to get things building natively and the binaries are far larger, so I'm going to go with "yeah".

And I'm hardly a fan of Go.

emccue12• 4 years ago

Hypothetically there is a version of "static Java" that could start to encroach upon Go's domain. This may or may not come out of Project Leyden, but I think for the reason the other commenter gave GraalVM isn't exactly it.

Still closer though, and GraalVM native images are pretty cool.

https://mail.openjdk.java.net/pipermail/discuss/2020-April/0...

klabb33• 4 years ago

Did you see the examples? Even with the blocking threaded style the Java versions gave me nightmares. And they didn't even bring up a cancelation example (not 100% sure on that). Cancelation and subsequent graceful shutdown is one of the hardest concurrency problems that (a) you are very likely to need in practice and (b) conveniently often are left out of example code. Heck it isn't even great in Go (too explicit imo) but at least they solved it.

emccue12• 4 years ago

Can you elaborate more?

All of the parts that throw `InterruptedException` are handling the thread interrupt cancelation mechanism.

There is also the example with the atomic boolean quit flag.

I'm not convinced that Go has any unique mechanisms here. Just like Java you can't forcefully kill a thread without that thread's cooperation.

latchkey3• 4 years ago

I deploy a single golang binary to well over 15k servers (many are only 100mbit) across many data centers and update it many times a day/week. Using xz, it compresses down to about 5mb.

As much as I love Java (I co-founded Apache Java), golang is a great fit for this usecase.

winrid• 4 years ago

Okay, I'll bite. So why not distribute a most likely even smaller jar file?

pjmlp2• 4 years ago

Only when one is forced to deal with Docker or k8s ecosystem stuff written in Go.

Or as a type safe C for userspace.

IceWreck• 4 years ago

Why not ? Go binaries don't require a seperate vm/runtime. Theyre faster in some cases and Go has overall simpler to read code than Java.

There is room enough for both languages.

kaba06• 4 years ago

The modern Java packaging also includes the runtime itself, there is not even a JRE anymore. And readability is somewhat subjective, Java is a really simple language, all the writer does is just method calls into various existing libraries. Since those didn’t get a chance to evolve yet with the upcoming virtual threads they are a bit longer at times.

So all what left is opinionated in-language support vs library support, and it is not clear cut which is the winner. Java seems to allow finer control over the primitives of concurrency, so a library or another JVM language could build up a much better abstraction over the mechanism.

nahuel0x2• 4 years ago

Golang still has an advantage over Java + Loom + Graalvm, JVM as a better GC but Golang using more inline/value types puts less pressure on it and diminishes memory usage. So you need to wait also for Java project Valhalla to match Golang profile.

sto_hristo• 4 years ago

I find it hard to be convinced to use GO at all. If i wanted efficiency, i'd bite and go with something close to the metal. If i wanted something that can build huge applications and has a rich framework ecosystem - i'd go with Java. GO seems like a middle solution for some exceptional cases, which i haven't deal with.

It is a fresh language and i quite enjoyed exploring it, but i just can't see the use of it. (also, the multiple return value functions are great, but if only there was a way to use a particular value directly from the function without having to assign them to variables)

sidcool2• 4 years ago

How is this different than Kotlin coroutines? They seem to already support this feature.

pjmlp2• 4 years ago

First class support on the JVM, instead of .class boilerplate emulating the feature, usable only for Kotlin.

emccue12• 4 years ago

The example I think is compelling is JDBC.

Nearly all SQL Database access goes through it and it won't be rewritten in any practical time scale. It can't be meaningfully async without a rewrite and kotlin's coroutines can't change that.

With virtual threads that synchronous api can be used at the performance level of what a hypothetical JDBC rewite would give.

(Not that you want to hit your DB that much, but you know what I mean. You don't need to specially wrap or bundle apis to get into an async call juggle.)

funcDropShadow2• 4 years ago

And the importance of this first class support cannot be overstated. It means: - meaningful complete stacktraces - debugger support - all blocking libraries get the benefits of async code automatically [1] - all monitoring features of the platform work - profilers get more useful again - less mental overhead when programming, i.e. simplicity

[1]: With one caveat: Libraries which call directly into blocking native calls do not become async automatically. But they are very rare on the Java platform.

jillesvangurp4• 4 years ago

Kotlin's co-routine framework will be able to use Loom style green threads as soon as it comes available. Until then, it uses its own callback based mechanism to schedule co-routines (very similar to using Futures or Promises technically).

If you are already using co-routines, there's very little you will need to do other than updating the library when they add the support for this. Other than that, it indeed already has essentially all of the feature set that Loom adds to Java. So, do several other frameworks like Spring's flux, vert.x, rx java, etc. Kotlin's co-routine framework actually has extension functions for all of these as well as things like threadpools, worker threads, etc. in Java.

The value of Loom is mainly adding low level JVM support for this. Other frameworks will evolve to use that as well. The Java API to this is probably not that interesting; even if you do use Java. You probably should be using something a bit higher level. There are quite many frameworks for Java implementing all sorts of ways to do the same things. All Loom does is add a few useful things for these frameworks to do their thing a bit faster.

Kotlin's co-routine library is actually a multiplatform library that works in natively compiled kotlin on IOS/linux/windows/etc. (and soon wasm), in kotlin-js in a browser or node.js, and in the JVM. On each of these platforms, it uses a platform specific implementation as well as ways to seamlessly interact with platform specific things (e.g. promises in a browser, futures, threadpools, spring fluxes, etc. on the JVM). So, how co-routines are executed and scheduled is platform specific. The resulting code tends to be very portable and look very similar. I actually maintain a few multi platform kotlin things that support co-routines and they work great on both the jvm and in a browser.

When Loom releases, it will just be yet another thing that co-routines can be executed with. On the JVM, you can trivially create a co-routine dispatcher from a thread pool. A co-routine dispatcher is basically where you schedule your suspend functions to run. Loom basically just provides alternate threadpool and thread implementations that follow the same API that use the underlying jvm functionality (which is the really interesting thing it adds). So, the changes for Kotlin's co-routine library to support this are going to be pretty minimal. In fact, a lot of its current extension functions should just work against the Loom API without any changes.

There's nothing in the Loom apis that is particularly interesting if you use co-routines but the low level JVM optimizations are of course interesting from a performance point of view. Also interesting is the improved ease of dealing with stack traces; which can be a bit of a pain point with co-routines on the jvm. So, lots of good reasons for Kotlin users to look forward to this but no big reason to wait for it. You can use co-routines right now and the same code will continue to work great when Loom gets there in an LTS version in a few years. But it might run a little faster and be a bit easier to debug.

truth_seeker• 4 years ago

Sounds like a nice strategy by Jetbrains. Thanks for sharing.

sidcool2• 4 years ago

Thanks for the detailed explanation.

MrBuddyCasino• 4 years ago

The interesting aspect is not "running Kotlin coroutines on Loom", but eliminating the need for source-level coroutine keywords and solving the problem of function coloring, no?

Skinney4• 4 years ago

You probably should be using something a bit higher level.

While there's nothing wrong in using something higher level, the main reason for using higher level libraries are because using threads doesn't scale past a certain point.

The problem with libraries that try to work around the scalability issue is one of compatibility. Using co-routines is great, but you need workarounds when targetting JDBC or a Http client. You have to be using coroutines, or coroutine friendly code, everywhere, or you risk reducing performance.

For this reason, we just use regular threads and threadpools in our projects. Once Loom lands we'll change the executors to spawn virtual threads and then we'll be done.

That said, coroutines shine if you can't wait for Loom to land or if you're targetting something other than the JVM (like Android).

orthogonal-wren2• 4 years ago

Good read! I just saw that in one examples you create and start a thread by invoking #startVirtualThread, and then you call start on the returned thread again.

emccue12• 4 years ago

Oof, fixed

funcDropShadow2• 4 years ago

Loom's virtual thread are much more similar to GHC's threads than to go routines. And GHC Haskell is also able to spawn millions of threads, trivially.

emccue12• 4 years ago

Can you elaborate more? What is the distinguishing factor?

ziihrs• 4 years ago

In Go, the select branch to take is non-deterministically chosen from the set of enabled branches. For the examples I don't think it makes a difference, but in general you cannot assume that a select attempts to choose branches from top to bottom.

Cthulhu_6• 4 years ago

I wonder if that's on purpose, to find bugs earlier. I know that the implementation of map in Go will intentionally shuffle the keys when you try to iterate over them, so that you never accidentally rely on insertion order.

yakubin• 4 years ago

I've read somewhere (possibly when Go came out) that it's on purpose. For fun, Alan Cox once made a post on Google+ (RIP) showing a crappy random number generator based on Go's select.

dgb23• 4 years ago

It's very much on purpose, just like default maps being unordered. People should not rely on the ordering as it breaks the semantics of these features according to Go. It fits the Go philosophy well.

Strum355• 4 years ago

Its non deterministic on purpose because thats how its required to be to fit the model of CSP (communicating sequential processes)

pron3• 4 years ago

People sometimes respond with some puzzlement to InterruptedException, unsure what they should do. All it means is that some other thread has requested that this thread stop what it's doing. So do what you think your code should do in that situation. E.g. in the case of `say`, the most reasonable thing is to simply return.

You shouldn't normally call `Thread.currentThread().interrupt()` inside a `catch (InterruptedException e)` unless, perhaps, you don't throw anything. That would prevent any blocking operation inside cleanup code from working. As a general rule, a thread's interrupt status is set or InterruptedException (or some other exception) is thrown, but not both. That is how JDK methods also do it. If they throw — they clear the interrupt status.

emccue12• 4 years ago

Aight.

I only started doing this recently after this advice here

https://discord.com/channels/544924237773668373/930457954346...

I'll clear it from the examples

K2L8M11N2• 4 years ago

Just FYI, that link is not publicly accessible.

xyproto2• 4 years ago

Judging by the examples, the Go code is easier to read, write and maintain.

ivolimmen• 4 years ago

Well as someone that has been developing software in Java for 20 years and never touched Go; it's the other way around.

Cthulhu_6• 4 years ago

Can you elaborate? I mean there may be some new operators and concepts in the Go versions, but they're explained succinctly in https://go.dev/tour/

doctor_eval• 4 years ago

I developed and maintained Java software professionally for over 20 years, since 1.0, but now I work in Go. There is no way I’d willingly go back to Java, and these examples really underscore some of the reasons.

I do however wonder, now, what I’m missing out on with other languages, particularly swift and rust.

threeseed• 4 years ago

That's more to do with your preferences.

For me Golang has far weaker and less flexible error handling semantics.

And concurrency is more verbose in Java but it's easy enough to abstract it behind a wrapper.

Where as you can't escape Golang's error handling.

Cthulhu_6• 4 years ago

Of course, you have to consider whether you SHOULD escape it.

I do believe you probably have more control over Java's threads, making them a bit more verbose. But, both Java itself - as you mention - and languages built on top of the JVM have ways to make it less verbose.

shp0ngle• 4 years ago

Well, that's because goroutines and channels are something, that's first class in go and has a special syntax.

While in Java, it tries to mostly keep the existing Java syntax.

I guess people that write Java are used to a lot of "lasagna" all-is-object boilerplate and ignore it. The same way go people are used to ignore the `err != nil` lines everywhere.

sdevonoes• 4 years ago

Judging by the examples, when it comes to code that deals with concurrency both Go and Java are difficult to maintain. Plenty of times I have dealt with "clever code" (written by others and by my past self) that works 99% of the time.

pron3• 4 years ago

The examples translate Go idioms directly to Java code rather than using Java idioms; you wouldn't normally write Java like Go any more than you'd write Go like Java.

They also make use of constructs that are overkill for such simple examples. For example, the first example could be written as:

   Thread.startVirtualThread(() -> say("world"));
   say("hello");

which would also replicate same concurrency bug as in the original Go program (the Java example, as written, does not have that bug, but neither would

   var t = Thread.startVirtualThread(() -> say("world"));
   say("hello");
   t.join();

Go makes certain concurrency bugs easy to introduce and hard to find, while Java helps avoid them, but that is also not easy to see from these particular examples.

dhab• 4 years ago

After mulling between Elixir vs Go to have a tool in the toolbelt covering the use-case of concurrent server-side apps, I picked a book on Go and went through the first chapter.

Disenchanted to hear (some) concurrency bugs easy to introduce and hard to find in Go. Could someone mention how does this compare to Elixir?

emccue12• 4 years ago

Yeah, sorry.

I would have used .startVirtualThread more if I wasn't under the impression that I needed to do Thread.currentThread().interrupt() when catching and re-throwing as a RuntimeException.

So I was choosing between the noise of that in the examples and the noise of the executor + submit with a lambda that returned null.

cle2• 4 years ago

Is there an idiom in Loom for cancellation propagation and deadlines? I can't find anything in https://download.java.net/java/early_access/loom/docs/api/ja... about it. Do we need to run a second virtual thread that waits on the cancellation condition and interrupts, and then handle that exception gracefully in the interrupted virtual thread?

nyanpasu64• 4 years ago

Interesting article history! Does your site have a RSS feed to keep up with updates in a feed reader? I couldn't find one.

matttproud• 4 years ago

In Go there is less noise, but also there no way to interrupt Go's time.Sleep.

You can do so in one of two ways using the context API (https://go.dev/blog/context) while keeping the code synchronous and idiomatic:

    package main
    
    import (
     "context"
     "fmt"
     "time"
    )
    
    func say(ctx context.Context, s string) {
     for i := 0; i < 5; i++ {
      select {
      case <-time.After(100 * time.Millisecond):
       fmt.Println(s)
      case <-ctx.Done():
       return // Operation canceled or timed out.
      }
     }
    }
    
    func main() {
     ctx := context.Background() // Use context cancellation semantics.
     go say(ctx, "world")
     say(ctx, "hello")
    }

If the code is reasonably performance sensitive AND there's a high degree of likelihood the context is canceled before the operation completes, you can use a time.Timer similar to what follows:

    for i := 0; i < 5; i++ {
     func(i int) { // Wrap in closure expressly to support defer statement.
      t := time.NewTimer(100 * time.Millisecond)
      defer t.Stop()
      select {
      case <-t.C:
       fmt.Println(s)
      case <-ctx.Done():
       return // Operation canceled or timed out.
      }
     }(i)
    }

deepsun• 4 years ago

Go solution to TreeWalk problem is wrong, or, rather, not real-world, because it has a memory leak. You need to make sure all goroutines finish, and not stuck on reading/writing to a channel.

In Kotlin coroutines you can .cancel() a coroutine, but Go doesn't allow to cancel goroutines.

Go's Concurrency Examples in Java 19

Related Stories