I thought that the Committed memory is automatically set to 1MB when the thread is created but it looks you are right! Thank you for your answer and explanation, I'll update the article :)
Hey Brian, I think this is only one of the approaches. It depends on what you want to do in the asynchronous part of your system. Let's say you are pushing entity (a picture) and you want to put it into the queue where 5 services will asynchronously consume this but only one is supposed to respond back (the crucial one - we always need to know if this services processed successfully). This way you can exploit a lot of advantages of queues ... e.g. persist the entity and process it later on. It's about your use-case :) .. I prefer not to bind services together with a synchronous execution and make a split as soon as possible, in this case in Rest APP to open the door for asynchronous chaos :) ... of course, you always need to wait for the response somewhere because of synchronous HTTP (if you don't use push model - SSE or WebSockets)
I am not a JVM expert but I would distinguish Allocated and Committed, we can see that in Java 8 JVM commits automatically 1MB per thread during the creation of the thread even if it's not fully allocated (used) but in Java 11 gradually commit the memory according to allocation - at least what I saw when I was doing my experiment.
You mean how the memory grows? The memory is not committed as whole at the very beginning of thread creation, it's committed after a smaller chunks, unfortunatelly I don't know tje algorithm behind this. However it's great, for example if you have let's say OpenShift and you specify that your application requests 500MB but can grow to 1GB then if your application creates a thread and don't actually use the threads (e.g. you have test environment which is mostly inactive) then your apps can report smaller amount of memory.
You mean, how fast does the thread commit the memory? in Java 8 it's automatically 1MB in Java 11 it gradually takes until 1MB, unfortunatelly I didn't find any article or JEP describing this process.
I don't wanna talk on behalf of other languages but, as far as I know, Java can figure out "effectively final" variables only inside methods. And if we are talking about Java Memory Model then it does not matter because you are still thread-confined. This article makes sense only in a case of global variables.
Yes, you are right! It's swapped, thanks! It always somehow limits possibilities to reorder the code because you introduce barriers in your code. However, it's a tiny impact for the great predictability of your code.
The problem is that JVM does absolutely no optimizations on FINAL keyword because it behaves very defensively "thanks to" frameworks like Spring which are based on making even final fields accessible to put some value there.
why another generator :( ... What is the support in Intellij idea, does it hide the class and field usage or saying that the class is used but is used only in generated code? Isn't better to use let's say .. Kotlin?
Exactly, a lot of stuff is hidden inside frameworks to make it "convenient" which is great for helloworld app, but in the end, we need to know what happens under the hood when the application is under the pressure!
Maybe you are right, hopefully, Lombok will stay simple (a lot of interesting frameworks started being simple and awesome and then contributors start adding complexity/features :) ) ... I see the different problem but maybe it's not a problem with Lombok, maybe just Lombok's users just tend to do so - my colleagues omit to add a final keyword, they want to have as small source code as possible and just add @Data annotation :)
I understand why people use Lombok, but for me it's the reason why I don't use groovy and other magic languages ... I want to see the code, I want to see that getter is not used and I can remove it, and so on ... to write 2 lines less does not mean that the code is more readible because of annotations ... great example is Spring Boot. Does anyone exactly know what all the annotations mean? And what is exactly autoconfigured during the startup? To have 2 less lines in source file does not mean cleaner code :)
CORE
Comments
Nov 21, 2019 · Petr Bouda
haha I know but it still not here and adaptation will be loong :) .. and still does not support all the cases where you can become blocked.
Nov 07, 2019 · Petr Bouda
Yes exactly, and the work on Asynchronous JDBC has been already stopped in a favour of coming Fibers :) - https://blogs.oracle.com/java/jdbc-next:-a-new-asynchronous-api-for-connecting-to-a-database
Jun 11, 2019 · Petr Bouda
Native Memory Tracking
- it tracks native memory of the JVM
- but as far as I know it's only internal JVM native memory, if you create your own native memory allocation then it's not included
Jun 08, 2019 · Petr Bouda
So that's the answer!!
I thought that the Committed memory is automatically set to 1MB when the thread is created but it looks you are right! Thank you for your answer and explanation, I'll update the article :)
Jun 08, 2019 · Petr Bouda
That's very interesting, thank you for your hint, I'll try to repeat the example with Zulu version. My example uses Oracle Hotspot.
Jun 08, 2019 · Petr Bouda
what version of Java?
Jun 06, 2019 · Petr Bouda
Hey Brian, I think this is only one of the approaches. It depends on what you want to do in the asynchronous part of your system. Let's say you are pushing entity (a picture) and you want to put it into the queue where 5 services will asynchronously consume this but only one is supposed to respond back (the crucial one - we always need to know if this services processed successfully). This way you can exploit a lot of advantages of queues ... e.g. persist the entity and process it later on. It's about your use-case :) .. I prefer not to bind services together with a synchronous execution and make a split as soon as possible, in this case in Rest APP to open the door for asynchronous chaos :) ... of course, you always need to wait for the response somewhere because of synchronous HTTP (if you don't use push model - SSE or WebSockets)
Jun 06, 2019 · Petr Bouda
sorry, don't understand :)
Jun 06, 2019 · Petr Bouda
Hey Bro :) ... hope you don't maintain any stuff in Java 8 anymore :)
Jun 05, 2019 · Petr Bouda
I am not a JVM expert but I would distinguish Allocated and Committed, we can see that in Java 8 JVM commits automatically 1MB per thread during the creation of the thread even if it's not fully allocated (used) but in Java 11 gradually commit the memory according to allocation - at least what I saw when I was doing my experiment.
Jun 05, 2019 · Petr Bouda
If you want to try interactive flame graphs, please, click on links below, right click on SVG and open it in a new tab.
https://github.com/petrbouda/rabbitmq-async-microservices/blob/master/blocking.svg
https://github.com/petrbouda/rabbitmq-async-microservices/blob/master/non-blocking.svg
Jun 04, 2019 · Petr Bouda
You mean how the memory grows? The memory is not committed as whole at the very beginning of thread creation, it's committed after a smaller chunks, unfortunatelly I don't know tje algorithm behind this. However it's great, for example if you have let's say OpenShift and you specify that your application requests 500MB but can grow to 1GB then if your application creates a thread and don't actually use the threads (e.g. you have test environment which is mostly inactive) then your apps can report smaller amount of memory.
Jun 04, 2019 · Petr Bouda
You mean, how fast does the thread commit the memory? in Java 8 it's automatically 1MB in Java 11 it gradually takes until 1MB, unfortunatelly I didn't find any article or JEP describing this process.
Jun 01, 2019 · Petr Bouda
I don't wanna talk on behalf of other languages but, as far as I know, Java can figure out "effectively final" variables only inside methods. And if we are talking about Java Memory Model then it does not matter because you are still thread-confined. This article makes sense only in a case of global variables.
Jun 01, 2019 · Petr Bouda
Yes, you are right! It's swapped, thanks! It always somehow limits possibilities to reorder the code because you introduce barriers in your code. However, it's a tiny impact for the great predictability of your code.
The problem is that JVM does absolutely no optimizations on FINAL keyword because it behaves very defensively "thanks to" frameworks like Spring which are based on making even final fields accessible to put some value there.
May 31, 2019 · Lindsay Burk
why another generator :( ... What is the support in Intellij idea, does it hide the class and field usage or saying that the class is used but is used only in generated code? Isn't better to use let's say .. Kotlin?
May 31, 2019 · Petr Bouda
Exactly, a lot of stuff is hidden inside frameworks to make it "convenient" which is great for helloworld app, but in the end, we need to know what happens under the hood when the application is under the pressure!
May 16, 2019 · Brian Hannaway
Yeap I know that there is Intellij Lombok plugin, but it hides the information that the getter and field is not used :(
May 16, 2019 · Brian Hannaway
Maybe you are right, hopefully, Lombok will stay simple (a lot of interesting frameworks started being simple and awesome and then contributors start adding complexity/features :) ) ... I see the different problem but maybe it's not a problem with Lombok, maybe just Lombok's users just tend to do so - my colleagues omit to add a final keyword, they want to have as small source code as possible and just add @Data annotation :)
May 15, 2019 · Brian Hannaway
I understand why people use Lombok, but for me it's the reason why I don't use groovy and other magic languages ... I want to see the code, I want to see that getter is not used and I can remove it, and so on ... to write 2 lines less does not mean that the code is more readible because of annotations ... great example is Spring Boot. Does anyone exactly know what all the annotations mean? And what is exactly autoconfigured during the startup? To have 2 less lines in source file does not mean cleaner code :)