Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upCollapse putobject, putobject, newarray #41
+95,354
−5,581
Conversation
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65858 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65859 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65860 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65861 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65862 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65863 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65864 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65865 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
…mingw32. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65866 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65867 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65868 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65869 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65870 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65871 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65872 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65873 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65874 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65875 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65876 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65877 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65878 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65879 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* common.mk (coroutine/amd64/Context.$(OBJEXT)): fix a typo, $(OBJECT). * common.mk (coroutine/amd64): recipe to make object directory. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65880 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65881 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
FIBER_USE_NATIVE is always defined as 0 or 1, use `#if` instead of `#ifdef`. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65882 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This is hoped to fix the SEGV: https://app.wercker.com/ruby/ruby/runs/mjit-test1/5bf392cf183106002856c1f0?step=5bf3bddc87436a0006292535 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65883 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
by r65880 https://travis-ci.org/ruby/ruby/jobs/457384539 git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65884 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
By the default of GNU make, .S is used to be compiled with CC, but we have already used .s as ia64.s, and now coroutine/*/Context.s. git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65885 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65886 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@65887 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
The ruby setting was renamed to HEAP_PAGE_ALIGN_LOG, but the configure.in (now configure.ac) file was not updated, so the setting had no effect. The configure setting is unnecessary after OpenBSD 5.2 and MirOS has been discontinued (with the last release being over 10 years ago), so it is better to just remove the related configure setting. Fix [Bug #13438] From: Jeremy Evans <code@jeremyevans.net> git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66086 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66087 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66089 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66090 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
* hash.c (linear_copy): solve two issues on `Hash#replace`.
(1) fix memory leak
(1-1) don't allocate memory if destination already
has a memory area.
(1-2) free destination memory if src is NULL.
(2) clear transient heap flag if src is NULL. [Bug #15358]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66091 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66092 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
There seems to be a compatibility problems with Rails + Rack::Deflater; so we revert this incompatibility. This effectively reverts r65922; but keeps the bugfixes to better support non-blocking sockets and pipes for future use. [Bug #15356] [Bug #14968] git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66093 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66094 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
In this example code:
```ruby
def foo
[1, 2, 3, 4]
end
```
The array literal uses a `duparray` instruction. Before this patch,
`rb_ary_resurrect` would malloc and memcpy a new array buffer. This
patch changes `rb_ary_resurrect` to use `ary_make_partial` so that the
new array object shares the underlying buffer with the array stored in
the instruction sequences.
Before this patch, the new array object is not shared:
```
$ ruby -r objspace -e'p ObjectSpace.dump([1, 2, 3, 4])'
"{\"address\":\"0x7fa2718372d0\", \"type\":\"ARRAY\", \"class\":\"0x7fa26f8b0010\", \"length\":4, \"memsize\":72, \"flags\":{\"wb_protected\":true}}\n"
```
After this patch:
```
$ ./ruby -r objspace -e'p ObjectSpace.dump([1, 2, 3, 4])'
"{\"address\":\"0x7f9a76883638\", \"type\":\"ARRAY\", \"class\":\"0x7f9a758af900\", \"length\":4, \"shared\":true, \"references\":[\"0x7f9a768837c8\"], \"memsize\":40, \"flags\":{\"wb_protected\":true}}\n"
```
[Feature #15289] [ruby-core:90097]
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66095 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
On my 32-bit x86 userspace, I get the following .text savings:
text data bss dec hex filename
152971 56 252 153279 256bf io.o.before
152863 56 252 153171 25653 io.o.after
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66096 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66097 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66098 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66099 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
postponed_job is safe to use in signal handlers, but is not thread-safe for MJIT. Implement a workqueue for MJIT thread-safety. [Bug #15316] git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66100 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
MJIT tests take longer than 100s on my VM :< git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66101 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66102 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66103 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
I think I finally fixed the underlying bug in r65937
("io.c (fptr_finalize_flush): close race leading to EBADF")
I've run this test over 100000 times on a multicore system, now.
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66104 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
This collapses: ``` == disasm: #<ISeq:bar@bench.rb:3 (3,0)-(5,3)> (catch: FALSE) 0000 putobject "a" ( 4)[LiCa] 0002 putobject "b" 0004 putobject "c" 0006 putobject "d" 0008 putobject "e" 0010 putobject "f" 0012 putobject "g" 0014 putobject "h" 0016 putobject "i" 0018 putobject "j" 0020 putobject "k" 0022 newarray 11 0024 leave ( 5)[Re] ``` In to this: ``` == disasm: #<ISeq:bar@bench.rb:3 (3,0)-(5,3)> (catch: FALSE) 0000 duparray ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k"]( 4)[LiCa] 0002 leave ( 5)[Re] ``` git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66106 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66107 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
git-svn-id: svn+ssh://ci.ruby-lang.org/ruby/trunk@66108 b2dd03c8-39d4-4d8f-98ff-823fe69b080e
tenderlove
force-pushed the
duparray
branch
4 times, most recently
from
61b7e39
to
0d96723
This collapses: ``` == disasm: #<ISeq:bar@bench.rb:3 (3,0)-(5,3)> (catch: FALSE) 0000 putobject "a" ( 4)[LiCa] 0002 putobject "b" 0004 putobject "c" 0006 putobject "d" 0008 putobject "e" 0010 putobject "f" 0012 putobject "g" 0014 putobject "h" 0016 putobject "i" 0018 putobject "j" 0020 putobject "k" 0022 newarray 11 0024 leave ( 5)[Re] ``` In to this: ``` == disasm: #<ISeq:bar@bench.rb:3 (3,0)-(5,3)> (catch: FALSE) 0000 duparray ["a", "b", "c", "d", "e", "f", "g", "h", "i", "j", "k"]( 4)[LiCa] 0002 leave ( 5)[Re] ```
jhawthorn
pushed a commit
that referenced
this pull request
Dec 13, 2019
This changeset makes no difference unless GC_DEBUG is on. When that flag is set, struct RVALUE is bigger than struct RObject. We have to take care of the additional fields. Otherwise we get a SIGSEGV like shown below. The way obj is initialized in this patch works for both GC_DEBUG is on and off. See also ISO/IEC 9899:1999 section 6.7.8 paragraph #21. ``` Program received signal SIGSEGV, Segmentation fault. __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 62 ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory (gdb) bt #0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62 #1 0x00005555557dd9a7 in BSD_vfprintf (fp=0x7fffffff6be0, fmt0=0x5555558f3059 "@%s:%d", ap=0x7fffffff6dd0) at vsnprintf.c:1027 #2 0x00005555557db6f5 in ruby_do_vsnprintf (str=0x555555bfc58d <obj_info_buffers+1325> "", n=211, fmt=0x5555558f3059 "@%s:%d", ap=0x7fffffff6dd0) at sprintf.c:1022 #3 0x00005555557db909 in ruby_snprintf (str=0x555555bfc58d <obj_info_buffers+1325> "", n=211, fmt=0x5555558f3059 "@%s:%d") at sprintf.c:1040 #4 0x0000555555661ef4 in rb_raw_obj_info (buff=0x555555bfc560 <obj_info_buffers+1280> "0x0000555555d2bfa0 [0 ] T_STRING (String)", buff_size=256, obj=93825000456096) at gc.c:11449 #5 0x000055555565baaf in obj_info (obj=93825000456096) at gc.c:11612 #6 0x000055555565bae1 in rgengc_remembered (objspace=0x555555c0a1c0, obj=93825000456096) at gc.c:6618 #7 0x0000555555666987 in newobj_init (klass=93824999964192, flags=5, v1=0, v2=0, v3=0, wb_protected=1, objspace=0x555555c0a1c0, obj=93825000456096) at gc.c:2134 #8 0x0000555555666e49 in newobj_slowpath (klass=93824999964192, flags=5, v1=0, v2=0, v3=0, objspace=0x555555c0a1c0, wb_protected=1) at gc.c:2209 #9 0x0000555555666b94 in newobj_slowpath_wb_protected (klass=93824999964192, flags=5, v1=0, v2=0, v3=0, objspace=0x555555c0a1c0) at gc.c:2220 #10 0x000055555565751b in newobj_of (klass=93824999964192, flags=5, v1=0, v2=0, v3=0, wb_protected=1) at gc.c:2256 #11 0x00005555556575ca in rb_wb_protected_newobj_of (klass=93824999964192, flags=5) at gc.c:2272 #12 0x00005555557f36ea in str_alloc (klass=93824999964192) at string.c:728 #13 0x00005555557f2128 in rb_str_buf_new (capa=0) at string.c:1317 #14 0x000055555578c66d in rb_reg_preprocess (p=0x555555cc8148 "^-(.)(.+)?", end=0x555555cc8152 "", enc=0x555555cc7c80, fixed_enc=0x7fffffff74e8, err=0x7fffffff75f0 "") at re.c:2682 #15 0x000055555578ea13 in rb_reg_initialize (obj=93825000046736, s=0x555555cc8148 "^-(.)(.+)?", len=10, enc=0x555555cc7c80, options=0, err=0x7fffffff75f0 "", sourcefile=0x555555d1a5c0 "lib/optparse.rb", sourceline=1460) at re.c:2808 #16 0x000055555578e285 in rb_reg_initialize_str (obj=93825000046736, str=93825000046904, options=0, err=0x7fffffff75f0 "", sourcefile=0x555555d1a5c0 "lib/optparse.rb", sourceline=1460) at re.c:2869 #17 0x000055555578ee02 in rb_reg_compile (str=93825000046904, options=0, sourcefile=0x555555d1a5c0 "lib/optparse.rb", sourceline=1460) at re.c:2958 #18 0x0000555555748dfb in rb_parser_reg_compile (p=0x555555d1f760, str=93825000046904, options=0) at parse.y:12157 #19 0x00005555557581c3 in parser_reg_compile (p=0x555555d1f760, str=93825000046904, options=0) at parse.y:12151 #20 0x00005555557580ac in reg_compile (p=0x555555d1f760, str=93825000046904, options=0) at parse.y:12167 #21 0x0000555555746ebb in new_regexp (p=0x555555d1f760, node=0x555555dece68, options=0, loc=0x7fffffff89e8) at parse.y:10072 #22 0x000055555573d1f5 in ruby_yyparse (p=0x555555d1f760) at parse.y:4395 #23 0x000055555574a582 in yycompile0 (arg=93825000404832) at parse.y:5945 #24 0x00005555558c6898 in rb_suppress_tracing (func=0x55555574a470 <yycompile0>, arg=93825000404832) at vm_trace.c:427 #25 0x0000555555748290 in yycompile (vparser=93824999283456, p=0x555555d1f760, fname=93824999283624, line=1) at parse.y:5994 #26 0x00005555557481ae in rb_parser_compile_file_path (vparser=93824999283456, fname=93824999283624, file=93824999283400, start=1) at parse.y:6098 #27 0x00005555557cdd35 in load_file_internal (argp_v=140737488331760) at ruby.c:2023 #28 0x00005555556438c5 in rb_ensure (b_proc=0x5555557cd610 <load_file_internal>, data1=140737488331760, e_proc=0x5555557cddd0 <restore_load_file>, data2=140737488331760) at eval.c:1128 #29 0x00005555557cb68b in load_file (parser=93824999283456, fname=93824999283624, f=93824999283400, script=0, opt=0x7fffffffa468) at ruby.c:2142 #30 0x00005555557cb339 in rb_parser_load_file (parser=93824999283456, fname_v=93824999283624) at ruby.c:2164 #31 0x00005555556ba3e1 in load_iseq_eval (ec=0x555555c0a650, fname=93824999283624) at load.c:579 #32 0x00005555556b857a in require_internal (ec=0x555555c0a650, fname=93824999284352, exception=1) at load.c:1016 #33 0x00005555556b7967 in rb_require_string (fname=93824999284464) at load.c:1105 #34 0x00005555556b7939 in rb_f_require (obj=93824999994824, fname=93824999284464) at load.c:811 #35 0x00005555558b7ae0 in call_cfunc_1 (recv=93824999994824, argc=1, argv=0x7ffff7ecd0a8, func=0x5555556b7920 <rb_f_require>) at vm_insnhelper.c:2348 #36 0x00005555558a8889 in vm_call_cfunc_with_frame (ec=0x555555c0a650, reg_cfp=0x7ffff7fccfa0, calling=0x7fffffffaab0, cd=0x555555d76a10, empty_kw_splat=0) at vm_insnhelper.c:2513 #37 0x000055555589fb5c in vm_call_cfunc (ec=0x555555c0a650, reg_cfp=0x7ffff7fccfa0, calling=0x7fffffffaab0, cd=0x555555d76a10) at vm_insnhelper.c:2538 #38 0x000055555589f22e in vm_call_method_each_type (ec=0x555555c0a650, cfp=0x7ffff7fccfa0, calling=0x7fffffffaab0, cd=0x555555d76a10) at vm_insnhelper.c:2924 #39 0x000055555589ef47 in vm_call_method (ec=0x555555c0a650, cfp=0x7ffff7fccfa0, calling=0x7fffffffaab0, cd=0x555555d76a10) at vm_insnhelper.c:3038 #40 0x0000555555866dbd in vm_call_general (ec=0x555555c0a650, reg_cfp=0x7ffff7fccfa0, calling=0x7fffffffaab0, cd=0x555555d76a10) at vm_insnhelper.c:3075 #41 0x00005555558ae557 in vm_sendish (ec=0x555555c0a650, reg_cfp=0x7ffff7fccfa0, cd=0x555555d76a10, block_handler=0, method_explorer=0x5555558ae5d0 <vm_search_method_wrap>) at vm_insnhelper.c:4021 #42 0x000055555587745b in vm_exec_core (ec=0x555555c0a650, initial=0) at insns.def:801 #43 0x0000555555899b9c in rb_vm_exec (ec=0x555555c0a650, mjit_enable_p=1) at vm.c:1907 #44 0x000055555589aaf0 in rb_iseq_eval_main (iseq=0x555555c1da80) at vm.c:2166 #45 0x0000555555641f0b in rb_ec_exec_node (ec=0x555555c0a650, n=0x555555c1da80) at eval.c:277 #46 0x0000555555641d62 in ruby_run_node (n=0x555555c1da80) at eval.c:335 #47 0x000055555557a188 in main (argc=11, argv=0x7fffffffc848) at main.c:50 (gdb) fr 7 #7 0x0000555555666987 in newobj_init (klass=93824999964192, flags=5, v1=0, v2=0, v3=0, wb_protected=1, objspace=0x555555c0a1c0, obj=93825000456096) at gc.c:2134 2134 if (rgengc_remembered(objspace, (VALUE)obj)) rb_bug("newobj: %s is remembered.", obj_info(obj)); (gdb) p ((struct RVALUE*)obj)->file $1 = 0x65a5992b0fb25ce7 <error: Cannot access memory at address 0x65a5992b0fb25ce7> (gdb) ```
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
tenderlove commentedOct 21, 2018
This collapses:
In to this: