harmony-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pavel Rebriy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (HARMONY-4554) [drlvm][thread] Double memory allocation on thread creation
Date Mon, 08 Oct 2007 09:57:50 GMT

    [ 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.


Mime
View raw message