Setting JVM parameters at runtime
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
Is it possible to change/modify/adding VM parameters after the JVM is already loaded (running)? If so, how can I do it?
java jvm ikvm
add a comment |
Is it possible to change/modify/adding VM parameters after the JVM is already loaded (running)? If so, how can I do it?
java jvm ikvm
add a comment |
Is it possible to change/modify/adding VM parameters after the JVM is already loaded (running)? If so, how can I do it?
java jvm ikvm
Is it possible to change/modify/adding VM parameters after the JVM is already loaded (running)? If so, how can I do it?
java jvm ikvm
java jvm ikvm
asked Nov 18 '09 at 6:38
GuyGuy
2801925
2801925
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
For properties you'd set via the -D
flag on the command line, you want System.setProperty. For example:
System.setProperty("propname", "hello world");
// ... later ...
String value = System.getProperty("propname");
Update:
You can't enable debugging dynamically, but you can enable debugging at startup but attach a debugger later. With the following, you can listen on port 12345 and start your program running right away (via suspend=n
). Then you can attach a debugger if/when you need to, detach the debugger, attach again later, etc.
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
Of course, this hurts performance even when the debugger isn't attached, so it only works well in dev/test code, not production. For that, you want logging, e.g. log4j.
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
add a comment |
A short answer is that you cannot change VM parameters at runtime. The Runtime class does expose some options such max memory. The main parameters such as max memory should only be set by an admin type allowing management of resources when multiple JVMs co exist on a machine. Allowing one JVM to get greedy and ask for lots and lots more than it was allocated would kill this constraint.
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
8
-1 It is possible to change VM parameters a runtime! Take a look atcom.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1754077%2fsetting-jvm-parameters-at-runtime%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
For properties you'd set via the -D
flag on the command line, you want System.setProperty. For example:
System.setProperty("propname", "hello world");
// ... later ...
String value = System.getProperty("propname");
Update:
You can't enable debugging dynamically, but you can enable debugging at startup but attach a debugger later. With the following, you can listen on port 12345 and start your program running right away (via suspend=n
). Then you can attach a debugger if/when you need to, detach the debugger, attach again later, etc.
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
Of course, this hurts performance even when the debugger isn't attached, so it only works well in dev/test code, not production. For that, you want logging, e.g. log4j.
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
add a comment |
For properties you'd set via the -D
flag on the command line, you want System.setProperty. For example:
System.setProperty("propname", "hello world");
// ... later ...
String value = System.getProperty("propname");
Update:
You can't enable debugging dynamically, but you can enable debugging at startup but attach a debugger later. With the following, you can listen on port 12345 and start your program running right away (via suspend=n
). Then you can attach a debugger if/when you need to, detach the debugger, attach again later, etc.
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
Of course, this hurts performance even when the debugger isn't attached, so it only works well in dev/test code, not production. For that, you want logging, e.g. log4j.
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
add a comment |
For properties you'd set via the -D
flag on the command line, you want System.setProperty. For example:
System.setProperty("propname", "hello world");
// ... later ...
String value = System.getProperty("propname");
Update:
You can't enable debugging dynamically, but you can enable debugging at startup but attach a debugger later. With the following, you can listen on port 12345 and start your program running right away (via suspend=n
). Then you can attach a debugger if/when you need to, detach the debugger, attach again later, etc.
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
Of course, this hurts performance even when the debugger isn't attached, so it only works well in dev/test code, not production. For that, you want logging, e.g. log4j.
For properties you'd set via the -D
flag on the command line, you want System.setProperty. For example:
System.setProperty("propname", "hello world");
// ... later ...
String value = System.getProperty("propname");
Update:
You can't enable debugging dynamically, but you can enable debugging at startup but attach a debugger later. With the following, you can listen on port 12345 and start your program running right away (via suspend=n
). Then you can attach a debugger if/when you need to, detach the debugger, attach again later, etc.
-Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=12345
Of course, this hurts performance even when the debugger isn't attached, so it only works well in dev/test code, not production. For that, you want logging, e.g. log4j.
edited Nov 18 '09 at 7:51
answered Nov 18 '09 at 6:57
Harold LHarold L
4,5362027
4,5362027
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
add a comment |
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
What about -X non standard options? especially -Xdebug and some other debugging flags?
– Guy
Nov 18 '09 at 7:23
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
I added an update with debugging info.
– Harold L
Nov 18 '09 at 7:51
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
Thanks you Harold!
– Guy
Nov 18 '09 at 8:02
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
@Guy if this answers your question please mark it as such, to (1) thank the person that helped you and (2) prompt others that are interested in the answer to your question that this solution works. Thanks.
– Waleed Al-Balooshi
Apr 25 '10 at 13:22
add a comment |
A short answer is that you cannot change VM parameters at runtime. The Runtime class does expose some options such max memory. The main parameters such as max memory should only be set by an admin type allowing management of resources when multiple JVMs co exist on a machine. Allowing one JVM to get greedy and ask for lots and lots more than it was allocated would kill this constraint.
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
8
-1 It is possible to change VM parameters a runtime! Take a look atcom.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
add a comment |
A short answer is that you cannot change VM parameters at runtime. The Runtime class does expose some options such max memory. The main parameters such as max memory should only be set by an admin type allowing management of resources when multiple JVMs co exist on a machine. Allowing one JVM to get greedy and ask for lots and lots more than it was allocated would kill this constraint.
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
8
-1 It is possible to change VM parameters a runtime! Take a look atcom.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
add a comment |
A short answer is that you cannot change VM parameters at runtime. The Runtime class does expose some options such max memory. The main parameters such as max memory should only be set by an admin type allowing management of resources when multiple JVMs co exist on a machine. Allowing one JVM to get greedy and ask for lots and lots more than it was allocated would kill this constraint.
A short answer is that you cannot change VM parameters at runtime. The Runtime class does expose some options such max memory. The main parameters such as max memory should only be set by an admin type allowing management of resources when multiple JVMs co exist on a machine. Allowing one JVM to get greedy and ask for lots and lots more than it was allocated would kill this constraint.
answered Nov 18 '09 at 6:57
mP.mP.
12.8k66194
12.8k66194
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
8
-1 It is possible to change VM parameters a runtime! Take a look atcom.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
add a comment |
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
8
-1 It is possible to change VM parameters a runtime! Take a look atcom.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
The java.lang.Runtime class can tell you what the maximum memory setting is, but it doesn't allow it to be changed.
– tgdavies
Nov 24 '09 at 11:26
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
@tdavies I know and i gave the reason why this value is immutable.
– mP.
Nov 24 '09 at 11:58
8
8
-1 It is possible to change VM parameters a runtime! Take a look at
com.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
-1 It is possible to change VM parameters a runtime! Take a look at
com.sun.management.HotSpotDiagnosticMXBean#setVMOption(String, String)
– Chriss
Sep 6 '12 at 8:31
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f1754077%2fsetting-jvm-parameters-at-runtime%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown