You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by "Aleksey Shipilev (JIRA)" <ji...@apache.org> on 2007/07/26 15:00:53 UTC
[jira] Created: (HARMONY-4554) [drlvm][thread] Double memory
allocation on thread creation
[drlvm][thread] Double memory allocation on thread creation
-----------------------------------------------------------
Key: HARMONY-4554
URL: https://issues.apache.org/jira/browse/HARMONY-4554
Project: Harmony
Issue Type: Bug
Components: DRLVM
Environment: at least Linux 32/64
Reporter: Aleksey Shipilev
Priority: Minor
Threading system allocates the memory for the thread two times.
It could be seen by running simple Thread Test (HARMONY-4489) with strace:
strace -tt ./java Test
Output:
<sleep 1000>
[pid 19592] 16:41:27.321882 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
[pid 19592] 16:41:27.321902 futex(0x8069214, FUTEX_WAKE, 1) = 0
# 1-st allocation
[pid 19592] 16:41:27.321937 mmap2(NULL, 122880, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0xffffcb20) = 0xffffffffd21cc000
[pid 19592] 16:41:27.321972 mprotect(0xd21cc000, 4096, PROT_NONE) = 0
[pid 19592] 16:41:27.321999 clone(Process 19647 attached
child_stack=0xd2bcc4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xd2bccbe8, tls=0xd2bccbe8, child_tidptr=0xffffcb14) = 19647
[pid 19592] 16:41:27.322038 gettimeofday({1184762487, 322049}, NULL) = 0
[pid 19592] 16:41:27.322065 futex(0x881613c, FUTEX_WAIT, 1, NULL <unfinished ...>
[pid 19647] 16:41:27.322090 gettid() = 19647
[pid 19647] 16:41:27.322113 sched_setparam(0, 0) = -1 EINVAL (Invalid argument)
[pid 19647] 16:41:27.322142 sched_getaffinity(19647, 32, { }) = 4
# 2-nd allocation
[pid 19647] 16:41:27.322174 mmap2(0xd2bad000, 122880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_GROWSDOWN, -1, 0xd2bcc25c) = 0xffffffffd2bad000
[pid 19647] 16:41:27.322206 mprotect(0xd2bbe000, 4096, PROT_NONE) = 0
[pid 19647] 16:41:27.322232 sigaltstack({ss_sp=0x1d2bae000, ss_flags=0x10000 /* SS_??? */, ss_size=17794520063944949760}, NULL) = 0
[pid 19647] 16:41:27.322267 futex(0x881613c, 0x4 /* FUTEX_??? */, 1 <unfinished ...>
[pid 19592] 16:41:27.322286 <... futex resumed> ) = 0
[pid 19592] 16:41:27.322303 futex(0x8816120, FUTEX_WAIT, 2, NULL <unfinished ...>
[pid 19647] 16:41:27.322320 <... futex resumed> ) = 1
[pid 19647] 16:41:27.322338 futex(0x8816120, FUTEX_WAKE, 1 <unfinished ...>
[pid 19592] 16:41:27.322356 <... futex resumed> ) = 0
[pid 19592] 16:41:27.322375 futex(0x8816120, FUTEX_WAKE, 1) = 0
[pid 19592] 16:41:27.322451 write(1, "\rstarted threads = 51", 21) = 21
[pid 19592] 16:41:27.322517 gettimeofday({1184762487, 322528}, NULL) = 0
[pid 19592] 16:41:27.322543 clock_gettime(CLOCK_REALTIME, {1184762487, 322554000}) = 0
[pid 19592] 16:41:27.322573 futex(0x8069230, FUTEX_WAIT, 103, {0, 999974000} <unfinished ...>
[pid 19647] 16:41:27.322592 <... futex resumed> ) = 1
[pid 19647] 16:41:27.322612 gettimeofday({1184762487, 322622}, NULL) = 0
[pid 19647] 16:41:27.322638 futex(0x87aa56c, FUTEX_WAIT, 52, NULL <unfinished ...>
<sleep 1000>
One could instrument mmap call and see whether allocation is actually called:
mmap(0, 122880, 7, 34, -1, 0)
mmap: ia64 address (nil) is MAP_FIXED = 0
mmap:caller is 0:0x5d9985:pthread_create(/lib/tls/libpthread.so.0) 1:0xffffc7a0:pthread_create((null)) 2:0:(null)((null))
mmap(0xd807d000, 122880, 3, 306, -1, 0)
mmap: ia32 address 0xd807d000-0xd80f8000 is MAP_FIXED = 0
mmap:caller is 0:0xf6d2c487:_Z15init_stack_infov(.../Harmony-r555193/bin/default/libharmonyvm.so) 1:0xd80fbe20:_Z15init_stack_infov((null)) 2:0:(null)((null))
So, one time the stack is allocated by pthreads, second time by Harmony itself.
On large amount of threads and/or large stacks Harmony will consume double of needed memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4554) [drlvm][thread] Double memory
allocation on thread creation
Posted by "Pavel Rebriy (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533083 ]
Pavel Rebriy commented on HARMONY-4554:
---------------------------------------
It could be a problem with init_stack_info() function which protects the end of stack by guard pages.
> [drlvm][thread] Double memory allocation on thread creation
> -----------------------------------------------------------
>
> Key: HARMONY-4554
> URL: https://issues.apache.org/jira/browse/HARMONY-4554
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: at least Linux 32/64
> Reporter: Aleksey Shipilev
> Priority: Minor
>
> Threading system allocates the memory for the thread two times.
> It could be seen by running simple Thread Test (HARMONY-4489) with strace:
> strace -tt ./java Test
> Output:
> <sleep 1000>
> [pid 19592] 16:41:27.321882 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
> [pid 19592] 16:41:27.321902 futex(0x8069214, FUTEX_WAKE, 1) = 0
> # 1-st allocation
> [pid 19592] 16:41:27.321937 mmap2(NULL, 122880, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0xffffcb20) = 0xffffffffd21cc000
> [pid 19592] 16:41:27.321972 mprotect(0xd21cc000, 4096, PROT_NONE) = 0
> [pid 19592] 16:41:27.321999 clone(Process 19647 attached
> child_stack=0xd2bcc4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xd2bccbe8, tls=0xd2bccbe8, child_tidptr=0xffffcb14) = 19647
> [pid 19592] 16:41:27.322038 gettimeofday({1184762487, 322049}, NULL) = 0
> [pid 19592] 16:41:27.322065 futex(0x881613c, FUTEX_WAIT, 1, NULL <unfinished ...>
> [pid 19647] 16:41:27.322090 gettid() = 19647
> [pid 19647] 16:41:27.322113 sched_setparam(0, 0) = -1 EINVAL (Invalid argument)
> [pid 19647] 16:41:27.322142 sched_getaffinity(19647, 32, { }) = 4
> # 2-nd allocation
> [pid 19647] 16:41:27.322174 mmap2(0xd2bad000, 122880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_GROWSDOWN, -1, 0xd2bcc25c) = 0xffffffffd2bad000
> [pid 19647] 16:41:27.322206 mprotect(0xd2bbe000, 4096, PROT_NONE) = 0
> [pid 19647] 16:41:27.322232 sigaltstack({ss_sp=0x1d2bae000, ss_flags=0x10000 /* SS_??? */, ss_size=17794520063944949760}, NULL) = 0
> [pid 19647] 16:41:27.322267 futex(0x881613c, 0x4 /* FUTEX_??? */, 1 <unfinished ...>
> [pid 19592] 16:41:27.322286 <... futex resumed> ) = 0
> [pid 19592] 16:41:27.322303 futex(0x8816120, FUTEX_WAIT, 2, NULL <unfinished ...>
> [pid 19647] 16:41:27.322320 <... futex resumed> ) = 1
> [pid 19647] 16:41:27.322338 futex(0x8816120, FUTEX_WAKE, 1 <unfinished ...>
> [pid 19592] 16:41:27.322356 <... futex resumed> ) = 0
> [pid 19592] 16:41:27.322375 futex(0x8816120, FUTEX_WAKE, 1) = 0
> [pid 19592] 16:41:27.322451 write(1, "\rstarted threads = 51", 21) = 21
> [pid 19592] 16:41:27.322517 gettimeofday({1184762487, 322528}, NULL) = 0
> [pid 19592] 16:41:27.322543 clock_gettime(CLOCK_REALTIME, {1184762487, 322554000}) = 0
> [pid 19592] 16:41:27.322573 futex(0x8069230, FUTEX_WAIT, 103, {0, 999974000} <unfinished ...>
> [pid 19647] 16:41:27.322592 <... futex resumed> ) = 1
> [pid 19647] 16:41:27.322612 gettimeofday({1184762487, 322622}, NULL) = 0
> [pid 19647] 16:41:27.322638 futex(0x87aa56c, FUTEX_WAIT, 52, NULL <unfinished ...>
> <sleep 1000>
> One could instrument mmap call and see whether allocation is actually called:
> mmap(0, 122880, 7, 34, -1, 0)
> mmap: ia64 address (nil) is MAP_FIXED = 0
> mmap:caller is 0:0x5d9985:pthread_create(/lib/tls/libpthread.so.0) 1:0xffffc7a0:pthread_create((null)) 2:0:(null)((null))
> mmap(0xd807d000, 122880, 3, 306, -1, 0)
> mmap: ia32 address 0xd807d000-0xd80f8000 is MAP_FIXED = 0
> mmap:caller is 0:0xf6d2c487:_Z15init_stack_infov(.../Harmony-r555193/bin/default/libharmonyvm.so) 1:0xd80fbe20:_Z15init_stack_infov((null)) 2:0:(null)((null))
> So, one time the stack is allocated by pthreads, second time by Harmony itself.
> On large amount of threads and/or large stacks Harmony will consume double of needed memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (HARMONY-4554) [drlvm][thread] Double memory
allocation on thread creation
Posted by "Aleksey Shipilev (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HARMONY-4554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12533130 ]
Aleksey Shipilev commented on HARMONY-4554:
-------------------------------------------
Pavel, actually guard page should be 4K for this run.
More likely, In the attached log guard page set up by:
[pid 19647] 16:41:27.322206 mprotect(0xd2bbe000, 4096, PROT_NONE) = 0
So I doubt that this is connected with guard pages.
> [drlvm][thread] Double memory allocation on thread creation
> -----------------------------------------------------------
>
> Key: HARMONY-4554
> URL: https://issues.apache.org/jira/browse/HARMONY-4554
> Project: Harmony
> Issue Type: Bug
> Components: DRLVM
> Environment: at least Linux 32/64
> Reporter: Aleksey Shipilev
> Priority: Minor
>
> Threading system allocates the memory for the thread two times.
> It could be seen by running simple Thread Test (HARMONY-4489) with strace:
> strace -tt ./java Test
> Output:
> <sleep 1000>
> [pid 19592] 16:41:27.321882 <... futex resumed> ) = -1 ETIMEDOUT (Connection timed out)
> [pid 19592] 16:41:27.321902 futex(0x8069214, FUTEX_WAKE, 1) = 0
> # 1-st allocation
> [pid 19592] 16:41:27.321937 mmap2(NULL, 122880, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0xffffcb20) = 0xffffffffd21cc000
> [pid 19592] 16:41:27.321972 mprotect(0xd21cc000, 4096, PROT_NONE) = 0
> [pid 19592] 16:41:27.321999 clone(Process 19647 attached
> child_stack=0xd2bcc4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0xd2bccbe8, tls=0xd2bccbe8, child_tidptr=0xffffcb14) = 19647
> [pid 19592] 16:41:27.322038 gettimeofday({1184762487, 322049}, NULL) = 0
> [pid 19592] 16:41:27.322065 futex(0x881613c, FUTEX_WAIT, 1, NULL <unfinished ...>
> [pid 19647] 16:41:27.322090 gettid() = 19647
> [pid 19647] 16:41:27.322113 sched_setparam(0, 0) = -1 EINVAL (Invalid argument)
> [pid 19647] 16:41:27.322142 sched_getaffinity(19647, 32, { }) = 4
> # 2-nd allocation
> [pid 19647] 16:41:27.322174 mmap2(0xd2bad000, 122880, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_GROWSDOWN, -1, 0xd2bcc25c) = 0xffffffffd2bad000
> [pid 19647] 16:41:27.322206 mprotect(0xd2bbe000, 4096, PROT_NONE) = 0
> [pid 19647] 16:41:27.322232 sigaltstack({ss_sp=0x1d2bae000, ss_flags=0x10000 /* SS_??? */, ss_size=17794520063944949760}, NULL) = 0
> [pid 19647] 16:41:27.322267 futex(0x881613c, 0x4 /* FUTEX_??? */, 1 <unfinished ...>
> [pid 19592] 16:41:27.322286 <... futex resumed> ) = 0
> [pid 19592] 16:41:27.322303 futex(0x8816120, FUTEX_WAIT, 2, NULL <unfinished ...>
> [pid 19647] 16:41:27.322320 <... futex resumed> ) = 1
> [pid 19647] 16:41:27.322338 futex(0x8816120, FUTEX_WAKE, 1 <unfinished ...>
> [pid 19592] 16:41:27.322356 <... futex resumed> ) = 0
> [pid 19592] 16:41:27.322375 futex(0x8816120, FUTEX_WAKE, 1) = 0
> [pid 19592] 16:41:27.322451 write(1, "\rstarted threads = 51", 21) = 21
> [pid 19592] 16:41:27.322517 gettimeofday({1184762487, 322528}, NULL) = 0
> [pid 19592] 16:41:27.322543 clock_gettime(CLOCK_REALTIME, {1184762487, 322554000}) = 0
> [pid 19592] 16:41:27.322573 futex(0x8069230, FUTEX_WAIT, 103, {0, 999974000} <unfinished ...>
> [pid 19647] 16:41:27.322592 <... futex resumed> ) = 1
> [pid 19647] 16:41:27.322612 gettimeofday({1184762487, 322622}, NULL) = 0
> [pid 19647] 16:41:27.322638 futex(0x87aa56c, FUTEX_WAIT, 52, NULL <unfinished ...>
> <sleep 1000>
> One could instrument mmap call and see whether allocation is actually called:
> mmap(0, 122880, 7, 34, -1, 0)
> mmap: ia64 address (nil) is MAP_FIXED = 0
> mmap:caller is 0:0x5d9985:pthread_create(/lib/tls/libpthread.so.0) 1:0xffffc7a0:pthread_create((null)) 2:0:(null)((null))
> mmap(0xd807d000, 122880, 3, 306, -1, 0)
> mmap: ia32 address 0xd807d000-0xd80f8000 is MAP_FIXED = 0
> mmap:caller is 0:0xf6d2c487:_Z15init_stack_infov(.../Harmony-r555193/bin/default/libharmonyvm.so) 1:0xd80fbe20:_Z15init_stack_infov((null)) 2:0:(null)((null))
> So, one time the stack is allocated by pthreads, second time by Harmony itself.
> On large amount of threads and/or large stacks Harmony will consume double of needed memory.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.