But even allowing for the JVM abstraction to use 300MB for t kotlinlang #compose-desktop

Channels

kotlin-foundation

compose-android

ohio-kotlin-users

kotlin-by-example

sofl-user-group

kotlin-multiplatform-contest

tricity-kotlin-user-group

kotlin-in-action

android-databinding

cincinnati-user-group

fluid-libraries

codemash-precompiler

kotlingforbeginners

jhipster-kotlin

prozis-android-backup

realworldkotlin

graviton-browser

spring-security

domain-driven-design

connect-audit-events

swiss-user-group

effectivekotlin

refactoring-to-kotlin

russian-kotlinasfirst

androidgithubprojects

introduce-yourself

pocketgitclient

effective-kotlin

algolialibraries

lambdaworld_cadiz

intellij-tricks

kotlin-pakistan

navigation-architecture-component

strife-discord-lib

machinelearningbawas

leedskotlinusergroup

stayhungrystayfoolish

kotest-contributors

practical-functional-programming

swagger-gradle-codegen

100daysofkotlin

kotlinultimatechallenge

pattern-matching

kotlinforbeginners

competitive-programming

compose-ui-showcase

competitivecoding

kotlin-data-storage

skia-wasm-interop-temp

java-to-kotlin-refactoring

event21-community-content

androidx-xprocessing

embedded-kotlin

fb-internal-demo

image-processing

myndocs-oauth2-server

kotlintest-devs

beepiz-libraries

kotlinprogrammers

cscenter-course-2016

k2-early-adopters

intellij-plugins

language-proposals

library-development

refreshversions

language-evolution

kotlinx-datetime

framework-elide

compose-desktop

jvm-ir-backend-feedback

android-architecture

100daysofkotlin-2021

github-workflows-kt

python-contributors

squarelibraries

arrow-contributors

codingconventions

getting-started

Title

d

darkmoon_uk

12/03/2021, 4:23 AM

But even allowing for the JVM abstraction; to use 300MB, for the functionality afforded, feels like it can be significantly optimised.

a

Aru

12/03/2021, 4:36 AM

Can you set the

-Xmx128m

to limit the memory? Will it lead to OOM for ToolBox size app?

d

darkmoon_uk

12/03/2021, 4:37 AM

Keen to try it @Aru. As you're suggesting, this is probably a more a question of how JVM Apps persuade you to claim memory in advance in general, rather than Toolbox specifically.

👍 1

I do wonder why JVM Apps are claiming so much memory far in advance though, it's not like the JVM runtime can't just ask the OS for more as needed, same as any other native App using

malloc

.

a

Aru

12/03/2021, 4:41 AM

Actually it doesn't have to be that way. JVM can request more memory as it grows. You can start with a smaller initial memory with

-Xms

and go from there.

➕ 2

I'm curious to know how the NativeImage conversion to native code by Graal will behave in terms of allocation.

d

darkmoon_uk

12/03/2021, 5:08 AM

So this being the case; my question becomes; why is the ToolBox distribution even configured to claim ~300MB up-front? Is it just what the packaging developer decided would be a 'reasonable maximum'? Why even start at 'maximum'? Wouldn't it be better to reduce this?

o

olonho

12/03/2021, 5:27 AM

This is reserved, but not committed memory.

d

darkmoon_uk

12/03/2021, 5:28 AM

This is more than 'annoying level of curiosity' on my part - I've seen memory usage levelled as a criticism of Toolbox and its tech-stack on other forums, so I'd like to defend it (and not defend the indefensible).

Reserved or Committed... is still unusable by other processes though. Best that can be said about Reserved is 'unlikely to grow further'.

o

olonho

12/03/2021, 7:15 AM

Nope, that’s not how virtual memory works, see https://en.m.wikipedia.org/wiki/Virtual_memory

d

darkmoon_uk

12/03/2021, 9:42 AM

Happy to learn more about this, I'll read into it, thanks.

#compose-desktop Join Slack