01:31
xardion has quit [Remote host closed the connection]
01:36
xardion has joined #jruby
01:53
akp has joined #jruby
02:46
Puffball has joined #jruby
02:59
kares has quit [Ping timeout: 256 seconds]
03:17
akp has quit [Remote host closed the connection]
04:18
enebo has quit [Ping timeout: 255 seconds]
04:19
enebo has joined #jruby
05:07
<
GitHub55 >
[jruby] kares closed pull request #5037: align C ported memsearch code - need to handle array[length] properly (jruby-9.1...fix-2036-9.1)
https://git.io/vAU9f
05:07
<
GitHub144 >
jruby/jruby-9.1 23f53d3 Karol Bucek: Merge pull request #5037 from jruby/fix-2036-9.1...
05:12
<
GitHub101 >
jruby/master cb53364 kares: align BigDecimal 'bare' exponent no longer allowed + tidy-up tests
05:12
<
GitHub101 >
jruby/master ad74415 kares: speed-up BigDecimal instantiation -> without Java regex matching
06:10
Puffball has quit [Remote host closed the connection]
06:11
Puffball has joined #jruby
06:11
Puffball has quit [Remote host closed the connection]
06:58
kares has joined #jruby
06:58
mkristian has joined #jruby
08:27
claudiuinberlin has joined #jruby
09:23
akp has joined #jruby
09:29
akp has quit [Ping timeout: 264 seconds]
10:13
drbobbeaty has joined #jruby
10:22
akp has joined #jruby
10:27
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
10:57
akp has quit [Remote host closed the connection]
10:58
akp has joined #jruby
11:03
akp has quit [Ping timeout: 240 seconds]
12:15
drbobbeaty has joined #jruby
12:21
shellac has joined #jruby
12:59
akp has joined #jruby
13:00
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
13:04
akp has quit [Ping timeout: 256 seconds]
14:31
akp has joined #jruby
14:58
claudiuinberlin has joined #jruby
15:15
<
GitHub105 >
jruby/jruby-readline-update d437392 Christian Meier: switch jruby-readline without shaded jline and without jar-dependencies
15:19
<
enebo >
lopex: thanks!
15:21
<
enebo >
kares: I can look more too (perhaps just a point at where I should look if so)
15:47
mkristian has quit [Quit: This computer has gone to sleep]
16:02
regedit has joined #jruby
16:02
xardion has quit [Remote host closed the connection]
16:08
xardion has joined #jruby
16:17
akp has quit [Remote host closed the connection]
16:38
akp has joined #jruby
16:45
<
lopex >
nirvdrum: which case slowed down the most from that benchmark ?
16:46
mkristian has joined #jruby
16:47
<
nirvdrum >
lopex: I'd have to re-run it, but I think the slow_blank? case was the most problematic.
16:47
mkristian has quit [Client Quit]
16:47
<
nirvdrum >
Both regressed, however.
16:47
mkristian has joined #jruby
16:47
<
lopex >
nirvdrum: for all the data ?
16:47
<
lopex >
i.e. strings
16:47
mkristian has quit [Client Quit]
16:48
<
nirvdrum >
lopex: I just deleted the cases that relied on the extension and then ran the benchmark with the remaining pure Ruby cases.
16:49
<
lopex >
nirvdrum: I'm going jmh I guess
16:49
<
nirvdrum >
I ran with joni 2.1.12 first, then 2.1.14e
16:50
<
nirvdrum >
And that uses benchmark-ips.
16:59
<
headius >
kares: have you looked any more at this proc binding JI leak thing?
16:59
<
headius >
I just updated...the IR reference is what's keeping it alive, but there's a separate bug why the associated proc+binding still survive after the call completes
16:59
<
headius >
I can't find a reference to it so far with vvm
17:01
<
headius >
brixen? in here?
17:05
<
headius >
kares enebo: I think I see it
17:05
<
headius >
the well I see something
17:06
<
headius >
the interface impl class (generated) has a static RuntimeCache object it uses for invoking the associated object
17:06
<
headius >
so that anchors the proc and its binding to the class
17:06
<
headius >
because it was called once
17:06
<
headius >
this is a side effect of call site caching and singleton classes we can't really avoid in general
17:06
<
headius >
the class should go away and with it the cache
17:07
<
headius >
the class appears to be loaded into a rooted JRubyClassLoader
17:07
<
headius >
or at least a JRubyClassLoader that's held by a frame further up in the stack
17:08
<
enebo >
headius: I don't think that IR reference is keeping it alive though
17:09
<
enebo >
If I change func to proc { func; 1 }.call that 1GB I made for @b never goes away
17:12
<
headius >
but I confirmed it's keeping the JavaClass instance alive at least
17:12
<
enebo >
well it may be I am just saying that proc change should kill that root
17:12
<
enebo >
yeah for sure the instance is leaking
17:15
<
headius >
ok right, I don't see any references from the JavaClass instance to the proc
17:15
<
headius >
so the JavaClass instance "leaks" because of the IR tmp, but the big data leaks for separate reason
17:25
<
headius >
kares, enebo: I summarized problem and possible fixes
17:29
<
lopex >
jeeze this jmh takes forever
17:32
<
headius >
lopex: looks fine to me
17:32
<
headius >
I am not a JMH expert
17:32
<
headius >
ok, gotta run for lunch
17:32
<
lopex >
I dont see any regressions yet
17:33
<
lopex >
few percent faster for new joni version
17:39
<
enebo >
lopex: nirvdrum is running on graal?
17:42
shellac has quit [Quit: Leaving]
17:42
<
lopex >
enebo: I assume
17:49
<
nirvdrum >
enebo: I think I ran both with and without Graal. But I'll give it another look.
17:50
<
nirvdrum >
I am still running Java 8.
17:51
<
nirvdrum >
I'll try your benchmark, too. It would be more pronounced with longer strings, tool.
18:05
<
enebo >
lopex: wow RubyString.setEncoding() just changes the bytelists encoding regardless of sharing O_o
18:06
<
lopex >
enebo: hmm, is it a bug actually ?
18:10
<
enebo >
lopex: perhaps someone removed modify()
18:30
<
GitHub170 >
[jruby] nomadium opened pull request #5042: Deprecate Data class (ruby-2.5...deprecate-data-class)
https://git.io/vAGDa
18:35
<
lopex >
enebo: but it wouldnt have to reallocate since is could switch to buffer share level
18:35
<
lopex >
and only create bytelist instanve
18:37
<
GitHub182 >
[jruby] nomadium opened pull request #5043: Module#attr, attr_accessor, attr_reader, attr_writer are now public (ruby-2.5...module-attr-methods-are-now-public)
https://git.io/vAGyO
19:41
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
19:48
subbu is now known as subbu|lunch
19:49
<
headius >
lopex: I'm not sure how well we're utilizing the two COW levels for strings at this point
19:50
<
headius >
generally I have always just called modify which I think does a full copy
19:51
drbobbeaty has quit [Read error: Connection reset by peer]
19:52
drbobbeaty has joined #jruby
19:53
<
lopex >
headius: yeah, it might be unecessary complexity
19:53
<
lopex >
headius: main point was ineffective calls like "a".strip
19:54
<
headius >
yeah I understand
19:54
<
headius >
really the buffer-sharing ought to live in ByteList itself and not be directly a part of RubyString logic
19:54
<
headius >
but there's a lot of things that should live in ByteList
19:56
<
lopex >
the levels are easy to remove though
19:56
bbrowning is now known as bbrowning_away
20:04
<
enebo >
I think if bytelist has cow it shoudl be a subtype or not a main feature
20:04
<
enebo >
I know COW helps in cases but I just dislike it at this point :)
20:09
claudiuinberlin has joined #jruby
20:12
<
headius >
it will all be moot once Ruby 3.0 makes strings immutable
20:14
subbu|lunch is now known as subbu
20:18
bbrowning_away is now known as bbrowning
20:46
<
enebo >
although immutable strings makes COW more attactive :)
20:46
<
GitHub114 >
jruby/jruby-9.1 f4df68b Charles Oliver Nutter: Bump size of core jar to accommodate updated libs.
20:47
akp has quit [Remote host closed the connection]
20:49
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
20:49
<
headius >
enebo: there's no W
20:49
<
headius >
it's just shared buffers then
20:50
<
headius >
all our bugs come from the W
20:50
<
headius >
interestingly the JVM folks gave up on shared buffers altogether because it wasn't better than just making more of them
20:50
<
headius >
now they're reconsidering it seems
20:53
<
lopex >
java 7 update 5 afaik
20:53
<
lopex >
at least in string
20:56
<
headius >
yeah somewhere around there
20:56
<
GitHub31 >
jruby/master ea6131a Charles Oliver Nutter: Merge branch 'jruby-9.1'
20:56
<
headius >
ok, that should resolve all unexpected failures on master too
20:56
<
headius >
ignoring these weird spurious timeouts that only seem to happen on Travis
20:58
claudiuinberlin has joined #jruby
20:59
damnski_ has joined #jruby
21:01
damnski has quit [Ping timeout: 240 seconds]
21:23
akp has joined #jruby
21:25
claudiuinberlin has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:27
akp has quit [Ping timeout: 268 seconds]
21:28
<
lopex >
nirvdrum: I have that regression
21:29
<
lopex >
pathological
21:29
<
lopex >
[x]+ agains long aaaa... for example
21:31
<
headius >
try it against java.util.regex
21:32
<
lopex >
headius: 20x slower in new joni for "a" * 4000
21:33
<
headius >
we need to get the TR benchmark CI set up somewhere for JRuby
21:33
<
lopex >
was looking in at wrong places
21:33
<
headius >
I just don't have funds to set up a VM
21:34
<
lopex >
something doesnt advance on opfail
21:37
<
lopex >
actually [x] is just x
21:37
claudiuinberlin has joined #jruby
21:39
<
enebo >
lopex: is it in newer mri vs older or was this more a factor of your recent engine changes?
21:39
<
lopex >
headius: some perf fuzzer would be cool
21:39
<
headius >
yeah MRI must not have this case?
21:39
<
lopex >
enebo: I wouldnt believe that
21:39
<
enebo >
we used to have some weird bench of regexps that ola made which represented things he found in Rails
21:40
<
enebo >
lopex: that == ?
21:40
<
lopex >
its the case :P
21:40
<
enebo >
I had an OR in my sentence
21:40
<
lopex >
that it's onigmo case
21:40
<
lopex >
I'll look at it tomorrow
21:40
<
enebo >
ah so onigmo changes likely
21:41
<
lopex >
er, that was as not the case being it mri changes
21:43
<
headius >
lopex: you're coming to Krakow in May
21:43
<
headius >
just letting you know
21:45
<
headius >
enebo and I will both be there for GeeCON, we'd like to buy you dinner or something
21:46
akp has joined #jruby
21:49
<
GitHub98 >
jruby/jruby-9.1 f72c1b9 Thomas E. Enebo: Fix regressions after chr fixes. uptoCommon was changing our single byte...
21:50
<
headius >
rtyler: hey, do we have a setup where we could throw some of these bigger test suites and see if these timeouts are real or not?
21:50
<
enebo >
so that was much more complicated than expected
21:50
<
headius >
I'm fed up with travis and its sporadic failures
21:51
<
headius >
they look very much like resource limitations
21:55
akp has quit [Ping timeout: 260 seconds]
21:56
<
lopex >
now it really looks like onigmo
21:56
<
lopex >
even on mri 2.3
21:58
<
headius >
oh really?
21:59
<
lopex >
check x+ against some long failing string
22:00
<
lopex >
any failing quantifier
22:01
<
GitHub110 >
[jruby] headius closed issue #5038: Bundler activates minitest from stdlib instead of installed gem after upgrading to RubyGems 2.7.5
https://git.io/vAtnX
22:04
akp has joined #jruby
22:08
akp has quit [Ping timeout: 240 seconds]
22:11
bbrowning is now known as bbrowning_away
22:16
akp has joined #jruby
22:21
akp has quit [Ping timeout: 276 seconds]
22:25
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
22:42
Puffball has joined #jruby