---
title: "Comment by j on \"Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.\" | Hashnode"
description: "well that's kinda true if you don't take the -Xss1024m attribute into account because now java also has 1GB stack size. also it depends heavily on the a"
url: "https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185"
---

[Discussion](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594)

Comment [Go vs Java in terms of memory efficiency. Beauty of go routines and their variable stack size limit.](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594)

[j](https://hashnode.com/@chilimatic)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185)

well that's kinda true if you don't take the

```
-Xss1024m
```

attribute into account because now java also has 1GB stack size.

also it depends heavily on the architecture. And I do like go more than Java.

Also it's unfair to compare a JIT / Runtime based system with a baremetal binary.

[Mark](https://hashnode.com/@mverleg)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185#reply-5c87970d2fed1e9e73535078)

But if anything, having a dynamically sized stack should be easier on a VM, right?

[j](https://hashnode.com/@chilimatic)

[Mar 12, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185#reply-5c879d7c8ed8afd37616074f)

[Mark](https://hashnode.com/@mverleg) well it depends on the architecture of the vm since the vm is just an abstraction to support multiple 'baremetal machines' below.

to be honest I am not quite sure what 'is easier' because using a normal stack based programming language probably is 'the easiest way'.

it's just a different compile target in the end. The OS-Kernel seams to be more relevant since even a 'dynamically sized stack' which in the end usually means either big memory copies or some type of pointer / fat pointer / reference / ... to the heap.

The thing about java is that as long as objects usually always live on the heap and are passed in as references. the only stack based variables you have are primitives like int for example.

but back to the point the allocation of memory is up to the VM so it can be seen easier from certain applied perspectives. The optimization and allocation is not really part of your application model anymore if you mean this with easier.

I think I need to read up on this a little more :) these are just my unfiltered thoughts. and i actually deleted a lot because I am sure I went off track with transformation problems and cpu architecture etc. call windows, stack based languages and such ;D ....

[PRASHANTH H N](https://hashnode.com/@prahashnode)

[Mar 13, 2019](https://hashnode.com/posts/go-vs-java-in-terms-of-memory-efficiency-beauty-of-go-routines-and-their-variable-stack-size-limit/5c87671166eb7a457cb5a594/comment/5c877c261d0e3dd05d9f2185#reply-5c8873efccbad0dc0937acb7)

Yes, java allocates memory in heap for every object that we create. But the thread that it creates will receive a fixed amount of stack size which may not be required at all.