Why Thread.sleep(0) can prevent gc in rocketmq?










4















Recently I read source code in RocketMQ , but I can`t understand this code. Why this code can prevent gc?



https://github.com/apache/rocketmq/blob/master/store/src/main/java/org/apache/rocketmq/store/MappedFile.java



for (int i = 0, j = 0; i < this.fileSize; i += MappedFile.OS_PAGE_SIZE, j++) 
byteBuffer.put(i, (byte) 0);
// force flush when flush disk type is sync
if (type == FlushDiskType.SYNC_FLUSH)
if ((i / OS_PAGE_SIZE) - (flush / OS_PAGE_SIZE) >= pages)
flush = i;
mappedByteBuffer.force();



// prevent gc
if (j % 1000 == 0)
log.info("j=, costTime=", j, System.currentTimeMillis() - time);
time = System.currentTimeMillis();
try
Thread.sleep(0);
catch (InterruptedException e)
log.error("Interrupted", e);












share|improve this question

















  • 1





    I'm pretty sure the documentation is lying to you. There is no way that I know of to prevent the garbage collector from running.

    – A Boschman
    Nov 13 '18 at 15:29











  • on a side note: sleep(0) is weird, as implementation can do nothing (cease execution for 0 ms corner case). Thread.yield might be preferable, but that's up to original author

    – Adam Kotwasinski
    Nov 13 '18 at 15:53















4















Recently I read source code in RocketMQ , but I can`t understand this code. Why this code can prevent gc?



https://github.com/apache/rocketmq/blob/master/store/src/main/java/org/apache/rocketmq/store/MappedFile.java



for (int i = 0, j = 0; i < this.fileSize; i += MappedFile.OS_PAGE_SIZE, j++) 
byteBuffer.put(i, (byte) 0);
// force flush when flush disk type is sync
if (type == FlushDiskType.SYNC_FLUSH)
if ((i / OS_PAGE_SIZE) - (flush / OS_PAGE_SIZE) >= pages)
flush = i;
mappedByteBuffer.force();



// prevent gc
if (j % 1000 == 0)
log.info("j=, costTime=", j, System.currentTimeMillis() - time);
time = System.currentTimeMillis();
try
Thread.sleep(0);
catch (InterruptedException e)
log.error("Interrupted", e);












share|improve this question

















  • 1





    I'm pretty sure the documentation is lying to you. There is no way that I know of to prevent the garbage collector from running.

    – A Boschman
    Nov 13 '18 at 15:29











  • on a side note: sleep(0) is weird, as implementation can do nothing (cease execution for 0 ms corner case). Thread.yield might be preferable, but that's up to original author

    – Adam Kotwasinski
    Nov 13 '18 at 15:53













4












4








4


0






Recently I read source code in RocketMQ , but I can`t understand this code. Why this code can prevent gc?



https://github.com/apache/rocketmq/blob/master/store/src/main/java/org/apache/rocketmq/store/MappedFile.java



for (int i = 0, j = 0; i < this.fileSize; i += MappedFile.OS_PAGE_SIZE, j++) 
byteBuffer.put(i, (byte) 0);
// force flush when flush disk type is sync
if (type == FlushDiskType.SYNC_FLUSH)
if ((i / OS_PAGE_SIZE) - (flush / OS_PAGE_SIZE) >= pages)
flush = i;
mappedByteBuffer.force();



// prevent gc
if (j % 1000 == 0)
log.info("j=, costTime=", j, System.currentTimeMillis() - time);
time = System.currentTimeMillis();
try
Thread.sleep(0);
catch (InterruptedException e)
log.error("Interrupted", e);












share|improve this question














Recently I read source code in RocketMQ , but I can`t understand this code. Why this code can prevent gc?



https://github.com/apache/rocketmq/blob/master/store/src/main/java/org/apache/rocketmq/store/MappedFile.java



for (int i = 0, j = 0; i < this.fileSize; i += MappedFile.OS_PAGE_SIZE, j++) 
byteBuffer.put(i, (byte) 0);
// force flush when flush disk type is sync
if (type == FlushDiskType.SYNC_FLUSH)
if ((i / OS_PAGE_SIZE) - (flush / OS_PAGE_SIZE) >= pages)
flush = i;
mappedByteBuffer.force();



// prevent gc
if (j % 1000 == 0)
log.info("j=, costTime=", j, System.currentTimeMillis() - time);
time = System.currentTimeMillis();
try
Thread.sleep(0);
catch (InterruptedException e)
log.error("Interrupted", e);









java garbage-collection rocketmq






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Nov 13 '18 at 15:13









stubenstuben

234




234







  • 1





    I'm pretty sure the documentation is lying to you. There is no way that I know of to prevent the garbage collector from running.

    – A Boschman
    Nov 13 '18 at 15:29











  • on a side note: sleep(0) is weird, as implementation can do nothing (cease execution for 0 ms corner case). Thread.yield might be preferable, but that's up to original author

    – Adam Kotwasinski
    Nov 13 '18 at 15:53












  • 1





    I'm pretty sure the documentation is lying to you. There is no way that I know of to prevent the garbage collector from running.

    – A Boschman
    Nov 13 '18 at 15:29











  • on a side note: sleep(0) is weird, as implementation can do nothing (cease execution for 0 ms corner case). Thread.yield might be preferable, but that's up to original author

    – Adam Kotwasinski
    Nov 13 '18 at 15:53







1




1





I'm pretty sure the documentation is lying to you. There is no way that I know of to prevent the garbage collector from running.

– A Boschman
Nov 13 '18 at 15:29





I'm pretty sure the documentation is lying to you. There is no way that I know of to prevent the garbage collector from running.

– A Boschman
Nov 13 '18 at 15:29













on a side note: sleep(0) is weird, as implementation can do nothing (cease execution for 0 ms corner case). Thread.yield might be preferable, but that's up to original author

– Adam Kotwasinski
Nov 13 '18 at 15:53





on a side note: sleep(0) is weird, as implementation can do nothing (cease execution for 0 ms corner case). Thread.yield might be preferable, but that's up to original author

– Adam Kotwasinski
Nov 13 '18 at 15:53












1 Answer
1






active

oldest

votes


















4














It does not.



Thread's sleep documentation states only:




Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.




What it means it can have side effect on the behaviour of the garbage collector.



By calling Thread.sleep(0), you are (potentially (it's a 0, so implementation could even ignore that)) switching context, and the parallel GC thread could be selected instead, to clean up other references.
The minor side effect is that you potentially run GC more often - what can prevent long-running garbage collections (you are increasing a chance of GC run every 1000 iterations).






share|improve this answer

























  • Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

    – stuben
    Nov 15 '18 at 7:02











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
);



);













draft saved

draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53284031%2fwhy-thread-sleep0-can-prevent-gc-in-rocketmq%23new-answer', 'question_page');

);

Post as a guest















Required, but never shown

























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes









4














It does not.



Thread's sleep documentation states only:




Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.




What it means it can have side effect on the behaviour of the garbage collector.



By calling Thread.sleep(0), you are (potentially (it's a 0, so implementation could even ignore that)) switching context, and the parallel GC thread could be selected instead, to clean up other references.
The minor side effect is that you potentially run GC more often - what can prevent long-running garbage collections (you are increasing a chance of GC run every 1000 iterations).






share|improve this answer

























  • Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

    – stuben
    Nov 15 '18 at 7:02
















4














It does not.



Thread's sleep documentation states only:




Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.




What it means it can have side effect on the behaviour of the garbage collector.



By calling Thread.sleep(0), you are (potentially (it's a 0, so implementation could even ignore that)) switching context, and the parallel GC thread could be selected instead, to clean up other references.
The minor side effect is that you potentially run GC more often - what can prevent long-running garbage collections (you are increasing a chance of GC run every 1000 iterations).






share|improve this answer

























  • Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

    – stuben
    Nov 15 '18 at 7:02














4












4








4







It does not.



Thread's sleep documentation states only:




Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.




What it means it can have side effect on the behaviour of the garbage collector.



By calling Thread.sleep(0), you are (potentially (it's a 0, so implementation could even ignore that)) switching context, and the parallel GC thread could be selected instead, to clean up other references.
The minor side effect is that you potentially run GC more often - what can prevent long-running garbage collections (you are increasing a chance of GC run every 1000 iterations).






share|improve this answer















It does not.



Thread's sleep documentation states only:




Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds, subject to the precision and accuracy of system timers and schedulers. The thread does not lose ownership of any monitors.




What it means it can have side effect on the behaviour of the garbage collector.



By calling Thread.sleep(0), you are (potentially (it's a 0, so implementation could even ignore that)) switching context, and the parallel GC thread could be selected instead, to clean up other references.
The minor side effect is that you potentially run GC more often - what can prevent long-running garbage collections (you are increasing a chance of GC run every 1000 iterations).







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 13 '18 at 15:52

























answered Nov 13 '18 at 15:37









Adam KotwasinskiAdam Kotwasinski

2,543827




2,543827












  • Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

    – stuben
    Nov 15 '18 at 7:02


















  • Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

    – stuben
    Nov 15 '18 at 7:02

















Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

– stuben
Nov 15 '18 at 7:02






Thanks! I saw someone has advised the project to remove it(github.com/apache/rocketmq/issues/522). And this suggestion was added to the 4.4.0 milestone.

– stuben
Nov 15 '18 at 7:02




















draft saved

draft discarded
















































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.




draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53284031%2fwhy-thread-sleep0-can-prevent-gc-in-rocketmq%23new-answer', 'question_page');

);

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







Popular posts from this blog

Use pre created SQLite database for Android project in kotlin

Darth Vader #20

Ondo