[#87773] timer thread [was Re: [ruby-alerts:7905] failure alert on trunk-asserts@silicon-docker (NG (r63844))] — Eric Wong <normalperson@...>
> test_all <main>: warning: pthread_create failed for timer: Resource temporarily unavailable, scheduling broken
3 messages
2018/07/04
[#87836] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been reported by ko1 (Koichi Sasada).
5 messages
2018/07/06
[#87838] Re: [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes
— Eric Wong <normalperson@...>
2018/07/06
ko1@atdot.net wrote:
[#87842] Re: [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes
— Koichi Sasada <ko1@...>
2018/07/07
On 2018/07/06 18:47, Eric Wong wrote:
[#87847] undefined symbol: mjit_init_p — Leam Hall <leamhall@...>
I pulled Ruby trunk on 3 Jul and am now getting errors similar to the
10 messages
2018/07/07
[#87849] Re: undefined symbol: mjit_init_p
— Takashi Kokubun <takashikkbn@...>
2018/07/07
As I told you, `make install` is needed to make Ruby work. Running
[#87852] Re: undefined symbol: mjit_init_p
— Benoit Daloze <eregontp@...>
2018/07/07
One more reason for https://bugs.ruby-lang.org/issues/13620 maybe? ;)
[#87859] Re: undefined symbol: mjit_init_p
— Eric Wong <normalperson@...>
2018/07/08
Benoit Daloze <eregontp@gmail.com> wrote:
[#87986] [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt — mame@...
Issue #14915 has been updated by mame (Yusuke Endoh).
5 messages
2018/07/18
[#87987] Re: [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt
— Eric Wong <normalperson@...>
2018/07/18
mame@ruby-lang.org wrote:
[#88000] Re: [Ruby trunk Feature#14915] Deprecate String#crypt, move implementation to string/crypt
— "Urabe, Shyouhei" <shyouhei@...>
2018/07/19
normalperson (Eric Wong) wrote:
[#88088] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — normalperson@...
Issue #14937 has been reported by normalperson (Eric Wong).
9 messages
2018/07/24
[#88104] [Ruby trunk Bug#14898] test/lib/test/unit/parallel.rb: TestSocket#test_timestamp stuck sometimes — ko1@...
Issue #14898 has been updated by ko1 (Koichi Sasada).
3 messages
2018/07/25
[#88173] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — Greg.mpls@...
Issue #14950 has been reported by MSP-Greg (Greg L).
3 messages
2018/07/29
[#88189] [Ruby trunk Bug#14950] r64109 thread.c: move ppoll wrapper before thread_pthread.c - Windows compile failure - thread.c — nobu@...
Issue #14950 has been updated by nobu (Nobuyoshi Nakada).
3 messages
2018/07/30
[#88199] [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention — takashikkbn@...
Issue #14937 has been updated by k0kubun (Takashi Kokubun).
7 messages
2018/07/30
[#88213] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/07/30
takashikkbn@gmail.com wrote:
[#88219] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/07/30
> yet, sky3 had a failure at
[#88306] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/08/06
> http://ci.rvm.jp/results/trunk@P895/1173951
[#88308] Re: [Ruby trunk Misc#14937] [PATCH] thread_pthread: lazy-spawn timer-thread only on contention
— Eric Wong <normalperson@...>
2018/08/06
> > http://ci.rvm.jp/results/trunk@P895/1173951
[ruby-core:87872] [Ruby trunk Bug#14900] Extra allocation in String#byteslice
From:
samuel@...
Date:
2018-07-08 03:31:46 UTC
List:
ruby-core #87872
Issue #14900 has been updated by ioquatix (Samuel Williams).
I think there are several things to consider here:
- Even though the string appears to be two allocations, it's only one allocation but the 2nd one is sharing the first's data.
- I guess that subsequent slice would share the underling frozen string?
- In some cases, byteslice might be less efficient, e.g. 100Mbyte buffer, slice the last 10bytes, it makes an entire copy of the source string, but all you were interested in was 10 bytes at the end.
----------------------------------------
Bug #14900: Extra allocation in String#byteslice
https://bugs.ruby-lang.org/issues/14900#change-72885
* Author: janko (Janko Marohnić)
* Status: Open
* Priority: Normal
* Assignee:
* Target version:
* ruby -v: ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-darwin17]
* Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
When executing `String#byteslice` with a range, I noticed that sometimes the original string is allocated again. When I run the following script:
~~~ ruby
require "objspace"
string = "a" * 100_000
GC.start
GC.disable
generation = GC.count
ObjectSpace.trace_object_allocations do
string.byteslice(50_000..-1)
ObjectSpace.each_object(String) do |string|
p string.bytesize if ObjectSpace.allocation_generation(string) == generation
end
end
~~~
it outputs
~~~
50000
100000
6
5
~~~
The one with 50000 bytes is the result of `String#byteslice`, but the one with 100000 bytes is the duplicated original string. I expected only the result of `String#byteslice` to be amongst new allocations.
If instead of the last 50000 bytes I slice the *first* 50000 bytes, the extra duplication doesn't occur.
~~~ ruby
# ...
string.byteslice(0, 50_000)
# ...
~~~
~~~
50000
5
~~~
It's definitely ok if the implementation of `String#bytesize` allocates extra strings as part of the implementation, but it would be nice if they were deallocated before returning the result.
EDIT: It seems that `String#slice` has the same issue.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>