pitr-ch has quit [Ping timeout: 244 seconds]
enebo has quit [Quit: enebo]
pitr-ch has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pitr-ch has quit [Ping timeout: 244 seconds]
pitr-ch has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
e_dub has quit [Quit: ZZZzzz…]
camlow32_ has quit []
pitr-ch has quit [Ping timeout: 276 seconds]
pitr-ch has joined #jruby
pitr-ch has quit [Ping timeout: 276 seconds]
pitr-ch has joined #jruby
e_dub has joined #jruby
pitr-ch has quit [Ping timeout: 260 seconds]
pawnbox has joined #jruby
pitr-ch has joined #jruby
<nirvdrum> headius: Sorry, just saw this. Are you still around?
pawnbox has quit [Ping timeout: 240 seconds]
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch_ has joined #jruby
pitr-ch_ has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pawnbox has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pawnbox has quit [Ping timeout: 250 seconds]
<GitHub44> [jruby] chrisseaton pushed 1 new commit to truffle-head: https://git.io/vrBMn
<GitHub44> jruby/truffle-head 279e0bd Chris Seaton: Merge branch 'master' into truffle-head
pitr-ch has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
<travis-ci> jruby/jruby (truffle-head:279e0bd by Chris Seaton): The build was broken. (https://travis-ci.org/jruby/jruby/builds/131306287)
johnsonch_afk is now known as johnsonch
pitr-ch has quit [Ping timeout: 276 seconds]
pitr-ch has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 240 seconds]
nirvdrum has quit [Ping timeout: 276 seconds]
Aethenelle has quit [Quit: Aethenelle]
johnsonch is now known as johnsonch_afk
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 244 seconds]
e_dub has quit [Quit: It's a hard knock life]
pitr-ch has joined #jruby
pitr-ch has quit [Ping timeout: 246 seconds]
e_dub has joined #jruby
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
pawnbox has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
yfeldblum has quit [Remote host closed the connection]
yfeldblum has joined #jruby
thedarkone2 has quit [Quit: thedarkone2]
skade has joined #jruby
donV has joined #jruby
skade has quit [Ping timeout: 250 seconds]
<GitHub18> [jruby] kares reopened pull request #3383: public org.jruby.Runtime.Profile.Builtin::MethodData (jruby-1_7...public_o_j_r_profile_builtin_MethodData) https://git.io/vCG2v
skade has joined #jruby
skade has quit [Client Quit]
elia has joined #jruby
skade has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
yfeldblum has quit [Ping timeout: 240 seconds]
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
pitr-ch has joined #jruby
brauliobo has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
yfeldblum has joined #jruby
pitr-ch has quit [Ping timeout: 240 seconds]
pitr-ch has joined #jruby
pawnbox has quit [Ping timeout: 240 seconds]
skade has joined #jruby
pawnbox has joined #jruby
yfeldblum has quit [Ping timeout: 250 seconds]
skade has quit [Quit: Computer has gone to sleep.]
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
donV has quit [Quit: donV]
skade has joined #jruby
shellac has joined #jruby
donV has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
skade has quit [Quit: Computer has gone to sleep.]
pitr-ch has joined #jruby
skade has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
skade has quit [Quit: Computer has gone to sleep.]
pitr-ch has joined #jruby
skade has joined #jruby
Prasun has joined #jruby
yfeldblum has joined #jruby
yfeldblum has quit [Ping timeout: 250 seconds]
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pawnbox_ has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
pitr-ch has quit [Read error: Connection reset by peer]
vyorkin has joined #jruby
pitr-ch has joined #jruby
vyorkin has quit [Client Quit]
vyorkin has joined #jruby
vyorkin has quit [Client Quit]
vyorkin has joined #jruby
vyorkin has quit [Client Quit]
skade has quit [Quit: Computer has gone to sleep.]
Prasun has quit [Ping timeout: 246 seconds]
pitr-ch has quit [Ping timeout: 250 seconds]
pawnbox_ has quit [Ping timeout: 244 seconds]
shellac has quit [Quit: Computer has gone to sleep.]
pawnbox has joined #jruby
pitr-ch has joined #jruby
pawnbox has quit [Remote host closed the connection]
pawnbox has joined #jruby
cremes has quit [Read error: Connection reset by peer]
cremes has joined #jruby
pawnbox has quit [Ping timeout: 246 seconds]
Prasun has joined #jruby
donV has quit [Quit: donV]
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
elia has quit [Quit: Computer has gone to sleep.]
donV has joined #jruby
donV has quit [Client Quit]
pawnbox has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
donV has joined #jruby
skade has joined #jruby
grs has quit [Ping timeout: 260 seconds]
skade has quit [Quit: Computer has gone to sleep.]
grs has joined #jruby
shellac has joined #jruby
nirvdrum has joined #jruby
skade has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
elia has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pawnbox has quit [Read error: Connection reset by peer]
pawnbox has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
skade has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
bbrowning_away is now known as bbrowning
Prasun has quit [Ping timeout: 276 seconds]
skade has joined #jruby
pitr-ch has quit [Ping timeout: 276 seconds]
Prasun has joined #jruby
pitr-ch has joined #jruby
pitr-ch has quit [Ping timeout: 244 seconds]
pitr-ch has joined #jruby
lance|afk is now known as lanceball
tcrawley-away is now known as tcrawley
pitr-ch has quit [Ping timeout: 240 seconds]
pitr-ch has joined #jruby
<headius> good morning
Prasun has quit [Ping timeout: 276 seconds]
<nirvdrum> Howdy.
pitr-ch has quit [Ping timeout: 240 seconds]
pitr-ch has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
Prasun has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch_ has joined #jruby
pawnbox_ has joined #jruby
skade has joined #jruby
Aethenelle has joined #jruby
<headius> nirvdrum: what fixed those errors on Windows for you?
<headius> or did they just go away?
pawnbox has quit [Ping timeout: 260 seconds]
johnsonch_afk is now known as johnsonch
pawnbox_ has quit [Remote host closed the connection]
pitr-ch_ has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pitr-ch has quit [Read error: Connection reset by peer]
pitr-ch has joined #jruby
pawnbox has joined #jruby
<nirvdrum> headius: The ones I fixed a week or so back?
<headius> yeah
<headius> it looked like the same set failing for me yesterday
<nirvdrum> It was a few things.
<nirvdrum> Path canonicalization not working quite the way I thought: https://github.com/jruby/jruby/commit/fdb2b6db617dce3efcdc1ba484bb40bffb49f601
pawnbox has quit [Remote host closed the connection]
<nirvdrum> Truffle not having a native Windows part yet: https://github.com/jruby/jruby/commit/dd81c00f69d50e38d6a17be79044b11e756f0b95
pawnbox has joined #jruby
<nirvdrum> Which failure are you seeing?
pitr-ch has quit [Ping timeout: 260 seconds]
pitr-ch has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
skade has joined #jruby
enebo has joined #jruby
pitr-ch has quit [Ping timeout: 276 seconds]
cprice404 has quit [Remote host closed the connection]
cprice is now known as cprice404
pitr-ch has joined #jruby
fuzzyhorns has joined #jruby
<fuzzyhorns> Dir.glob doesnt work in jars, how should i handle that?
pitr-ch has quit [Read error: Connection reset by peer]
<fuzzyhorns> ah I see i need to use Dir[]
pitr-ch has joined #jruby
<headius> lopex: hey, question for you
<headius> nirvdrum: maybe it wasn't the same then...I was getting all those "symbol not found" errors during tck
<headius> lopex: looking at the alloc profile for brakeman, the #1 and #2 items are ByteCodeMachine
<headius> something like 1M of them allocated during the period I profiled
<headius> I'll try a depth=0 profile to get a total, but I have to wonder if we can be doing something there
grs has quit [Ping timeout: 260 seconds]
thedarkone2 has joined #jruby
skade has quit [Quit: Computer has gone to sleep.]
<nirvdrum> headius: That's the classloader issue.
<headius> nirvdrum: I just started seeing it
<headius> it sure felt like an environment thing...one day clean build just started tck erroring
<nirvdrum> It occurs to me I fixed this in "jt", but not in maven.
<headius> this was the jruby.home fix?
<nirvdrum> Yes.
<nirvdrum> It's because I started auto-requiring rubygems, which we look up relative to lib packaged in the JAR.
<nirvdrum> But maven does this isolated classloader thing that puts the root in /tmp.
skade has joined #jruby
<headius> ah, lovely
<headius> ok then two things
<headius> 1. point me toward the fix or see if you can do it to maven too
<enebo> headius: do you think brakeman might be doing many captures?
<headius> 2. can we disable your tck for normal builds, like -Ptest does for core?
<nirvdrum> Correction. The classloader root just can't find the file and JRuby falls over to /tmp.
<headius> enebo: not really, this is all through strscan
<headius> it's just that the main lexer loop is a big (not giant) case/when where each when is a scanner.scan(/something/)
<nirvdrum> I'm not sure why JRuby falls over to /tmp, since I think that's always going to problematic, but it's done that for a long time.
<headius> nirvdrum: I think it was a last effort to get a home to run from
<headius> if we can't find anything any other way
<nirvdrum> headius: I think we could disable the test. In fact, I thought eregon had for all but the "mvn test" task.
<headius> core skips tests by having that maven skiptests property default to false except in -Ptest
<headius> er vice versa
<nirvdrum> So what this did was set an argLine for surefire that sets the jruby.home system property, avoiding the classloader search.
donV has quit [Ping timeout: 260 seconds]
<nirvdrum> Sorry, I wasn't thinking about -Ptest. Otherwise I would've just fixed this in the POM.
<nirvdrum> It looks to me this has been problematic for a long time. I just happened to be the first unlucky person to really try loading anything from jruby.home during a unit test.
<headius> nirvdrum: if you think there's something we can improve in JRuby for this, let's do it
<headius> hmm
<headius> so I think just adding jruby.home setup to truffle's pom should fix this
pawnbox_ has joined #jruby
<lopex> headius: no more info wrt that allocs ?
<nirvdrum> Not that I'm shifting blame. It just took me a while to track down the root cause.
<headius> lopex: I was doing a total count but it was taking forever
<headius> it's millions anyway for this app (brakeman scanning redmine)
<lopex> headius: in most cases there shouldnt be any allocs in there
<enebo> It was why I wondered about captures
<headius> but it's a new machine every time we match, right?
<nirvdrum> headius: Probably. This is where I plead a bit of maven ignorance.
<lopex> headius: only for case insensitive matching if any
<lopex> enebo: ah the captures
pawnbox has quit [Read error: No route to host]
<nirvdrum> headius: If we could do it for the test profile in general, I think that'd be better.
<headius> profiles are per-module anyway
<headius> (I think)
<lopex> enebo: I dont think so
<enebo> but it appears to generate match data which appears to just be offsets
<headius> anyway -Ptest lives in core, not root
<lopex> headius: nit depends
<nirvdrum> Otherwise, a year or two from now when you add a new unit test, we'll be trying to figure all this out again :-/
grs has joined #jruby
<headius> lopex: hmm
<lopex> headius: String#scan reuses all of it for example
<enebo> lopex: yeah headius was right but I guess you still need to allocate the start/end boundary of the match
<lopex> headius: unless you deleted that optz
<nirvdrum> And again, sorry for breaking things here.
<headius> lopex: I may have :-D
<lopex> headius: same for gsub, split etc
<headius> nirvdrum: no worries, I'm just tidying some things up
<lopex> headius: but the machine is no a heavy object
<headius> enebo: we need to decide what to do about 9.1.1
<lopex> anyways
<enebo> headius: is this stringscanner.scan or string.scan
<headius> release without the bundler issues totally resolved or keep trying to find that
<headius> enebo: stringscanner.scan
<enebo> headius: ok…we make a new matcher every time but I guess the data will change over time
<lopex> headius: maybe some stack cache issue ?
<headius> lopex: not heavy, I'm just seeing it at the top of object profiles
<enebo> although we could probably update an existing matcher too
<headius> and this is a very hot loop
<enebo> seems like it would not be massive htough to store a few fields
<enebo> in the bytecode machine
<enebo> hmm
<headius> obviously the fact that it's a case/when blows too but that's not easy to change
<headius> next_token is the hot one
<headius> no amount of case/when trickery will help us here
<headius> ok, maybe it is a giant case/when
skade has quit [Quit: Computer has gone to sleep.]
<headius> nirvdrum: if fixing it in maven works you should be able to remove your patch too
<headius> I'm testing now
<nirvdrum> Yeah. All I did was specify a command-line option to maven anyway.
<enebo> headius: I think I see one capture at least in this code
<lopex> enebo: in general, rematch shouldnt use any allocs
<lopex> if the matcher is reused
<enebo> regexp for alternation (a|b) is still a capture right?
<enebo> I guess I might be wrong there
<lopex> even capture struct is reused
<enebo> lopex: so there is one per thread?
<lopex> enebo: one macher ?
<enebo> lopex: Matcher matcher = pattern.matcher(value.getUnsafeBytes(), value.getBegin() + pos, value.getBegin() + value.getRealSize());
<enebo> lopex: this makes a new object no?
<lopex> yes
<headius> and then stores it in a thread-local for the task it runs
<lopex> but it can be reused for String#scan for example
<enebo> lopex: it is not what headius was talking about but we do not really need a new one neccesarily
camlow325 has joined #jruby
<headius> right, if it were possible to reset a matcher/bytecodemachine we'd allocate far fewer things
<lopex> reset ?
<enebo> lopex: I am not so concerned with making an object per regexp search as it seems regexp machine execution will be so much more than this
<lopex> enebo: the execution should allocate anything
<lopex> *shouldnt
<lopex> except for stack
<enebo> lopex: well I think this all started because headius sees ByteCodeMaechine alloc’ing
<headius> yes
<lopex> enebo: then it's a bug somewhere
<headius> not Matcher...BCMs, lots of 'em
<headius> ok, I like to hear that :-)
<enebo> headius: although this bench is zillions of scans
<enebo> headius: I would expect to see many machines set up
<lopex> repeatStk is also prealloced
<lopex> headius: maybe it just sees it through stack cache ?
<lopex> it will be huge potentially
<lopex> and it's weak ref
<lopex> so it can dominated, yes
<lopex> *dominate
<headius> lopex: busted cache could easily explain it
Aethenelle has quit [Quit: Aethenelle]
grs has quit [Ping timeout: 260 seconds]
e_dub has quit [Read error: Connection reset by peer]
<headius> I had to break some paths that cached regex because of fixes to regex init that didn't seem to fit right
<enebo> wow this code is really a torture test for us :)
<lopex> and most is case insensitive
e_dub has joined #jruby
<headius> nirvdrum: I have fixes for both skip tests and that classloader thing, shall I just commit? You'll need to adjust whatever runs tck in CI to use -Ptest
<headius> enebo: indeed
<headius> this is the one we were talking about on our way out of RailsConf
<headius> one of the few examples out there that's clearly slower on JRuby than MRI
<headius> so...opportunities
<enebo> hahah yeah
<enebo> I mean we would like to make this at least as fast as MRI but I sort of feel like Ruby needs a nicer lexer for people to use than doing this
<headius> that's for sure
<headius> I assume this is one reason YorickPeterse switched to a native lexer
<lopex> headius: do you have a timing prfile as well ?
<headius> this is also one reason I am very suspicious of PEGs as the future of parsing
<headius> given that most pegs I've seen just use regexp
<enebo> yeah this is just doing a lot of slightly repetitive checks then jumping into a another case/when which is a method call
<lopex> but it's all single thread
<lopex> so the only possibility is huge stack and deep backtracks
<enebo> headius: yeah I have wondered how well PEGs could use some algebra to become a pangea expression
<headius> enebo: that might be possible here too
<enebo> heh
skade has joined #jruby
<enebo> not here but with something like this I guess
<headius> lopex: timing profile?
<headius> next_token is all over CPU profile
<enebo> if we at least knew contract for strscan.skip we could at least dramatically simpliy all these nested case/whens
<nirvdrum> headius: Go for it. I'll update jt.rb.
<enebo> heh headius hahaha….just change all these case whenres to if elsif
<enebo> it will get a lot smaller and will also be faster but who wants to do that much typing :)
<headius> it might get a little smaller
<headius> our case/when in IR is not ideal yet
<fuzzyhorns> looking at Dir["file:#{File.expand_path(Dir.pwd)}/glob-test.jar!/glob_target/**/*"] in https://github.com/jruby/jruby/blob/master/spec/java_integration/utilities/jar_glob_spec.rb
<enebo> well it should be since we do not have to eqqinstr all over the place
<headius> it may not cache still
<fuzzyhorns> i'm always going to have to check if i'm in a jar or not when i do Dir right?
<enebo> both will stil have the beq but one will not have this extra result
<enebo> At least I think so
<enebo> but these case/when is just for code aesthetics they cannot take advantage of an optimized case/when anyways
<GitHub56> [jruby] headius pushed 2 new commits to master: https://git.io/vr0vi
<GitHub56> jruby/master 15b34cc Charles Oliver Nutter: Skip JRuby+Truffle TCK unless -Ptest.
<GitHub56> jruby/master d706786 Charles Oliver Nutter: Provide jruby.home to Surefire to get a proper home.
<headius> nirvdrum: ^
<headius> fuzzyhorns: if Dir.glob doesn't work against classloader URIs we should fix that
<headius> is that what you mean?
<nirvdrum> Thanks.
<nirvdrum> I have a messy workspace at the moment, but I'll fix in a bit.
grs has joined #jruby
<fuzzyhorns> headius: i might be doing something wrong, but in my app, i have the dirs that respect this glob "app/endpoints/**/*.rb"
<fuzzyhorns> headius: but in a jar, this glob fails
<fuzzyhorns> headius: so i thought, oh well it is probably in a app_name/app dir now because warble, but that doesnt work either
<fuzzyhorns> i'm trying to avoid having to check whether or not i am in a jar before i check for these files but it may be impossible
skade has quit [Quit: Computer has gone to sleep.]
<headius> yeah I understand
<headius> maybe you can spell out what you're doing in an issue and we can try to find a better way
<headius> or on mailing list
<fuzzyhorns> this is a jruby issue you think, not a warble one?
<headius> it could be either
<headius> I mean, I'd expect us to try to keep it opaque whether you're in a jar and things just work too
<headius> so if you can't do that either we need to improve something or warbler does
skade has joined #jruby
donV has joined #jruby
<headius> the char[] could be a worry...might be using String too heavily somewhere
<headius> going to char[] and back to take advantage of some Java API for example
skade has quit [Client Quit]
pitr-ch has quit [Ping timeout: 246 seconds]
<lopex> headius: then there's so many matchers
pitr-ch has joined #jruby
<lopex> and no StackEntry there too
<headius> I'll split up by 10-deep stack trace
<lopex> headius: can you try to reuse them as we do for literals
<headius> char[] falls way off when I do that
<headius> reuse the matcher...like pooled on the RubyRegexp or something?
<lopex> not pooled, at sites
<headius> hmm
<headius> it would have to be at the .scan site
Aethenelle has joined #jruby
<headius> these aren't normal matches
<lopex> yeah
<lopex> hm
<lopex> looking at strscan
<headius> with ten-deep stacks, top two items are now BytecodeMachine, and they're both from scan
<lopex> oh, you also removed quoting caches
<headius> #4 is also BCM
<headius> quoting caches...ok
<lopex> but that's another thing
<headius> I'd love help restoring those caches
<lopex> headius: does heap show anything ?
<headius> when I re-ported some of the regexp init stuff I couldn't figure out right place to put caching back
<lopex> oh, nvm
<headius> heap?
<headius> ok
<lopex> I confused alloced object by BCM with BMC itself for a second
<headius> ok
<lopex> headius: but is the number of BCMs with a number of maches there ?
<lopex> on par ?
<lopex> goh, need to wake up
<headius> I forgot BCM < Matcher
<lopex> it's the same instance
<headius> yeah
<lopex> er, same thing
<lopex> all to minimize the allocations
<lopex> headius: but on single threaded code one can reuse matchers at =~sites
<lopex> I think
<headius> sure, those already get a bit of special treatment
<headius> I don't see how to reset the matcher and use it again
<lopex> enebo: is there a reason named captures dont work for locals when regexp is on right hand site ?
<lopex> headius: just matchAt again
<headius> hmm
<lopex> headius: there is no inbetween state, the IP for example always starts from the beginning
<enebo> lopex: yeah I don’t remember the justification for that
<enebo> lopex: it is a rule but every time I have used it I always do it that way and it does not work :)
<lopex> headius: I hope I'm not lying to you
<headius> lopex: I see no matchAt...and no way to give it a new byte[] to match against
<headius> hmm
<headius> maybe new byte[] isn't important
<lopex> headius: it's internal, then matchInterruptible
<lopex> oh I also see new SearchMatchTask per match
hobodave has joined #jruby
<headius> that's there too
<headius> may be able to tweak that to pool instances
pitr-ch has quit [Ping timeout: 250 seconds]
<headius> hmmm
<headius> strscan could have a mapping from regex to matcher
<headius> source shouldn't change
<lopex> hmm, my old code also reused MatchData too
<headius> MatchData shouldn't be getting constructed here
<lopex> I remember us being dozens times faster than mri
<headius> since we go directly into pattern
<headius> MatchData sharing is mostly off again but that shouldn't affect this
pitr-ch has joined #jruby
<lopex> yeah, just looking at the code
<enebo> seems like you would never have a strscan instance with ever growing patterns against it but I guess that could get protected against
<GitHub150> [jruby] mooreniemi opened issue #3904: in jar: require works but Dir[]/Dir.glob dont? https://git.io/vr0tG
<enebo> perhaps size protect it and then hash of patterns
<enebo> or matchers…whatever
<eregon> headius: do Truffle tests are run with -Ptests? Not intended indeed, and at least it won't on Java 7 right?
<eregon> are*
<headius> eregon: -Ptest just enables them, nothing else changes
<headius> enebo: I'm trying a naive map now
<headius> it would only grow as much as there are unique regex being used
<headius> and when strscanner goes away, they'd go away
<enebo> yeah
<enebo> so long as it does not have a source= method on it you would not expect it to run away
<headius> might be worth a look at MRI strscan too
<headius> have not looked at their impl in a long time, they may have added caching
<lopex> I dont see any
<headius> huh...my cache doesn't seem to help
<headius> oh
<headius> maybe I should actually populate it
<headius> I'm trying to think of real issues caused by a hard cache of Regex => Matcher in strscan
<travis-ci> jruby/jruby (master:d706786 by Charles Oliver Nutter): The build has errored. (https://travis-ci.org/jruby/jruby/builds/131436898)
<headius> it would need to be thread local
<headius> so there's that
<enebo> any caching with that needs to be anyways
<headius> yeah
<enebo> I was even wondering about current impl because we update a field on scan
<headius> hmm
<headius> so it may not be thread-safe anyway
<eregon> headius: Travis doesnt run them because -Ptest is run on JDK7, so is this locally?
<enebo> yeah currentMatcher is only one of 4-5 fields
<headius> eregon: yeah locally...nirvdrum said he would fix jt for you
<headius> to pass -Ptest appropriately
<eregon> hum I'm confused now
<eregon> one can always do --project '!truffle' if you don't want to build/test truffle for a given maven command
<headius> yes, that's not inconvenient at all :-)
<eregon> fair enough :p
<headius> I'm fine building truffle, but the rest of build has skipTests default to off and truffle didn't
<eregon> ah ok yeah that would be good to change
<headius> and it was a small change anyway...just need to update travis so it's building with -Ptest when you want tck
<eregon> yeah absolutely, I just misundertood
<headius> ok, so my strscan cache seems flawed somehow
<GitHub187> jruby/master 534cb71 Benoit Daloze: [Truffle] Normalize transfer before insert() to not invalidate....
<GitHub187> [jruby] eregon pushed 2 new commits to master: https://git.io/vr0Ow
<GitHub187> jruby/master 1a7e030 Benoit Daloze: [Truffle] Remove most of transferToInterpreter.
<headius> matcher == null || matcher.getRegex() != pattern || matcher.getBytes() != value.getUnsafeBytes()
<headius> should be enough no?
Prasun has quit [Ping timeout: 252 seconds]
<headius> start and end get passed into matchInterruptible
<lopex> is it a prepared one ?
<headius> yes
<headius> if that's recompiling every time it won't work but I don't see a lot of Regex getting created
<eregon> UnsafeBytes maybe has an offset if it's a ByteList?
<eregon> value.getUnsafeBytes() *
<lopex> headius: there
<lopex> headius: there's already caches for that
norc has joined #jruby
<lopex> headius: but it's not as bad now since joni now uses original byte arrays for templates
<lopex> headius: oni copies everything everytime
<headius> this doesn't seem to reset the matcher well enough
<lopex> it doesnt match ?
<headius> I get an error from brakeman that looks like it failed to match
<headius> trying to add more clearing logic to matcher
<headius> to clear region etc
blandflakes has joined #jruby
<headius> huh, still no good
<headius> aargh
<headius> what isn't getting reset
shellac has quit [Quit: Computer has gone to sleep.]
shellac has joined #jruby
lacce has joined #jruby
shellac has quit [Client Quit]
pglombardo has joined #jruby
pglombardo has quit [Client Quit]
shellac has joined #jruby
<travis-ci> jruby/jruby (master:1a7e030 by Benoit Daloze): The build failed. (https://travis-ci.org/jruby/jruby/builds/131452530)
elia has quit [Quit: Computer has gone to sleep.]
<headius> well I'm out of ideas
pitr-ch has quit [Read error: Connection reset by peer]
<headius> I feel like I'm resetting everything that can be reset on ByteCodeMachine
pitr-ch has joined #jruby
<lopex> is start/end/range ok there ?
<headius> I'll show you the diff
<headius> seems like I'm clearing all state that isn't final but it still breaks in brakeman
<headius> I feel like I'm clearing *more* than I need
skade has joined #jruby
<headius> mmm I found a leak
<headius> well, a small one
<headius> I guess only leaking one WeakRef per thread: static final ThreadLocal<WeakReference<StackEntry[]>>
<headius> that will cause classloader stickiness though too
<headius> lopex: what am I not clearing properly? :-(
<lopex> headius: hard to say without reduced code
<GitHub140> [jruby] Capncavedan closed issue #3867: JRuby 9.1.0.0 error running bundle exec cucumber on Travis https://git.io/vrUti
<headius> well perhaps, but the only thing I'm caching is the matcher, and I should be clearing everything
shellac has quit [Ping timeout: 260 seconds]
<headius> enebo: 3867 was just closed by user as no longer reproducible after fixing up his env
<headius> I think that's the last 9.1.1 blocker
<lopex> headius: can you set Config.DEBUG_SEARCH to true ?
<lopex> it will show you the positions
<enebo> hmm
<lopex> with and without caching
<headius> lopex: the large repro for this is simple btw...gem install brakeman, clone redmine/redmine, brakemane -q --sumary redmine
<headius> I imagine the smaller repro would involve just using ruby_parser aginst a bunch of sources
<enebo> yay ok well then I think we can go for it
<lopex> most of that shouldnt require clearing
<headius> lopex: figured as much but I was getting desperate
<lopex> headius: what different about this case and former matcher reuse in String ?
<lopex> matching against different strings ?
<headius> did it actually reuse matcher or just MatchData?
<lopex> headius: whole matcher
<headius> hmm
<lopex> for String#scan for example
<headius> I don't know
<lopex> but that might be different
<headius> this is always matching against the same string
<lopex> then I have no idea
<lopex> it worked that way
<lopex> just rematched with different start/range
Prasun has joined #jruby
<headius> hmm I don't see MatchData even holding a reference to the Matcher
<headius> just the regions in the matcher
<headius> lopex: doesn't that just create a new matcher every time?
adgtl has joined #jruby
adgtl has quit [Changing host]
adgtl has joined #jruby
<headius> I don't see any caching in it in joni
<lopex> headius: there's loop after that
<headius> oh ok
<lopex> so it clearly worked
<headius> yeah sequential matches with same matcher against same string
skade has quit [Quit: Computer has gone to sleep.]
<headius> lopex: are initial position/end used for anything?
<headius> since you have to pass them both into match* anyway
<lopex> headius: initial afaik is the whole string
<lopex> hmm, the String stuff needs some serious reoptimizations
<headius> yes please!
<lopex> or the widest region you're going to scan
<lopex> headius: even the captures were reused
<headius> yeah
<headius> chrisseaton: can jruby+truffle boot with gems yet?
<headius> maybe master is too far ahead of released graal but I can't get this to boot
<headius> lopex: I'm going to try setting start and end in my clear too
<headius> seems like the only thing left that would differ
fuzzyhorns1 has joined #jruby
<headius> lopex: that seems to have been the problem
<headius> it must be using "str" and "end" internally for something even with start/end passed into match?
norc has quit [Ping timeout: 252 seconds]
<lopex> headius: bytes/str/end is the whole string
<lopex> and those are final
<lopex> I'm confused
fuzzyhorns has quit [Ping timeout: 260 seconds]
<headius> and yet I needed to update them in clear for this to work
<headius> scan creates matcher repeatedly from begin + pos to begin + realSize
<headius> apparently that begin is important
<lopex> so there you go
<lopex> it should create on the whole range
<lopex> and then narrow in match
<headius> I made them non-final and made clear take begin + end
<lopex> I'd opt for my suggestion :)
<headius> you're saying pattern.match should be passing just begin and realsize every time?
<headius> I mean pattern.matcher
<headius> I'll try that and see if non-cached breaks
<lopex> on creation only
<headius> is there ever a reason to manually narrow it on create?
<headius> that's essentially what this is doing
<headius> as it advances the full match region shrinks from the front
<lopex> well, the string can be shared
<lopex> so you always need that
<headius> lopex: so what of this clearing I'm doing is unnecessary?
<headius> I feel like I'm doing too much clearing now
<lopex> headius: all
<headius> hah
<headius> well ok
<headius> I can certainly try just setting start and end and see what happens :-)
<headius> I'll try your suggestion as well
<lopex> headius: just the same thing like in the String#scan
<lopex> the only difference is that it would persist between method calls right ?
<headius> yes
<headius> and it may be matching from a different start every time
<headius> since we have multiple matchers interleaved
<headius> I mean it will be matching from a start that does not == where it ended before
oblutak has joined #jruby
momomomomo has joined #jruby
<headius> lopex: thought of one reason the rolling start position could be breaking this...if it ever needs to backtrack and rematch earlier bytes
<headius> the range check would fail since the match start is < string start in the matcher
<lopex> that's why you need to construct with full width
<lopex> I'm confused again
<headius> strscan.scan always creates matcher with pos as begin rather than string.begin
<headius> if I cache that matcher and a subsequent match wants to match something < pos, it would fail
<headius> I don't know that's happening here, but it's one possible reason
<headius> holy crap
<headius> either this is broken or it just went from 40s to 8s
<headius> lopex: no obvious breakage with no clear and just using full range, you rock
<headius> man I really hope this is not just broken
<headius> because we're way faster than MRI now
<lopex> headius: maybe it's also because of the MatchTask thingy ?
<lopex> headius: matcher itself is really really cheap
<enebo> OMGZZZZZ DARK MATTER
<headius> lopex: well I don't see it being that cheap
<headius> from BCM up there's almost a dozen reference fields and probably another dozen ints
<enebo> combine this with my defined? fix and startup time will go negative
<headius> not to mention realloc of Region, stack, others
<lopex> headius: right
<lopex> headius: well, if that dominates
<headius> the entire tree of objects is probably several hundred bytes
<lopex> the whole thing
<enebo> headius: can you print any output out and compare?
<headius> in a hot loop
<headius> enebo: it prints out summary of scan at the end along with timing
<enebo> seems to be the same
<headius> when my caching was broken it never finished because the parser failed
<headius> yeah same
<enebo> I guess you could also run the parser specs as well
<headius> except for 75% faster
<headius> this would be a home run if it's good
<lopex> headius: can you profile it ?
<headius> what do you want to see?
<lopex> headius: so now String literals would dominate ?
<lopex> allocation
<headius> I'll run a profile, gimme a sec
<headius> jesus, second time through, 6.497 seconds
<lopex> and mri is ?
<headius> something's wrong
<headius> it has to be
<headius> that's only like 4s of run time after startup
<lopex> mri does a lot more there
<lopex> it doesn have prepared cache
<headius> yeah but this is parsing all of redmine and running a bunch of scans over the AST
<headius> it should take more than 4s
<headius> yeah I think it's just erroring out
<headius> darn
<headius> lopex: so using full string width and caching that matcher without clear...does not work
<lopex> hm
<lopex> String#scan worked though with this
<headius> well I don't know if it did
<lopex> it did
<headius> it may have never matched properly and brakeman just raced through a bunch of empty ASTs
<lopex> ah, I mean the old String#scan impl
<headius> yeah but that's still different
<lopex> yeah
<headius> it doesn't need to change begin/end between match calls
<headius> I mean overall begin/end
<headius> that must have an effect on strscan's use
<headius> caching with clear doing nothing but begin/end reset also does not work
<lopex> I'd expect that at least
<headius> adding back more clearing stuff
<lopex> headius: maybe other StringScanner methods are affected ?
<lopex> wrt positions
<headius> well it's possible but at worst they should just still be making their own matcher
<headius> I only added the caching to scan
<headius> using full string range but creating a new matcher every time doesn't work either
<headius> I feel like there's something we're not getting
<lopex> if you change the meaning of full/width other methods might be affected
<enebo> how does skip interact with scan?
<enebo> you just modify mather to new pos?
<enebo> MATHER
e_dub has quit [Read error: Connection reset by peer]
e_dub has joined #jruby
dinfuehr_ has joined #jruby
donV has quit [Ping timeout: 276 seconds]
donV has joined #jruby
<GitHub62> [jruby] nirvdrum pushed 7 new commits to master: https://git.io/vr06D
<GitHub62> jruby/master 70d4d3a Kevin Menard: [Truffle] Fixed running on Graal when assertions are enabled.
<GitHub62> jruby/master 6302e6b Kevin Menard: [Truffle] Added support for running the optional C API specs.
<GitHub62> jruby/master cc08c24 Kevin Menard: [Truffle] Allow absolute output paths for jruby-cext-c.
pawnbox_ has quit [Ping timeout: 252 seconds]
dinfuehr_ has quit [Quit: dinfuehr_]
dinfuehr_ has joined #jruby
momomomomo has quit [Quit: momomomomo]
<headius> enebo: changing the case/when to if/else does not appear to change perf any
<headius> I did notice most of these whens are the "blank case" form that just checks truthy
<enebo> yeah I compared IR after I said that
<enebo> we get rid of some temp inits and an extra else jump
<enebo> but eqqinstr is replaced by a call
<enebo> and both are basically a beq
<enebo> since you made eqqinstr callsite cache that makes those more equal
<enebo> although I am now wonderingf if we should just make eqq an actual dispatch and not an instr
donV has quit [Quit: donV]
hobodave has quit [Quit: ["Textual IRC Client: www.textualapp.com"]]
norc has joined #jruby
bbrowning has quit [*.net *.split]
Puffball has quit [*.net *.split]
samuelkadolph has quit [*.net *.split]
headius has quit [*.net *.split]
Liothen has quit [*.net *.split]
Liothen has joined #jruby
Liothen has joined #jruby
Puffball has joined #jruby
headius has joined #jruby
samuelkadolph has joined #jruby
bbrowning has joined #jruby
knowtheory has quit [Ping timeout: 276 seconds]
knowtheory has joined #jruby
<headius> enebo: that's kinda what I was thinking too
<headius> we have some broken logic for `when ary` too right now
<enebo> headius: I think we had held off on this idea because it may be easier to detect the pattern of a case when
<enebo> headius: but I think we can still detect it with it/else
<enebo> headius: although it may be easier with eqq
<enebo> In other news I do not see any problems with our release bits
yfeldblum has joined #jruby
<travis-ci> jruby/jruby (master:35afc2c by Kevin Menard): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131488163)
pawnbox has joined #jruby
<nirvdrum> headius: Is there a way to force a build on CloudBees?
<nirvdrum> I'm interested in seeing if your maven fix gets the build green again.
subbu is now known as subbu|meeting
donV has joined #jruby
momomomomo has joined #jruby
<GitHub4> [jruby] headius tagged 9.1.1.0 at master: https://git.io/vr05g
<GitHub74> [jruby] headius deleted 9.1.1.0 at 35afc2c: https://git.io/vr0dI
<headius> stupid gh release notes
<headius> you can't create release notes without the tag existing...so it tagged for me
<headius> awful UI
<headius> nirvdrum: I can force it
<headius> which one?
<headius> oh, dist
<headius> yeah I'll punch it
momomomomo has quit [Ping timeout: 260 seconds]
lacce has quit []
<GitHub65> [jruby] enebo pushed 2 new commits to master: https://git.io/vr0du
<GitHub65> jruby/master fe84e89 Thomas E. Enebo: Update for release
<GitHub65> jruby/master 39db3ee Thomas E. Enebo: Merge branch 'master' of github.com:jruby/jruby
<GitHub45> [jruby] enebo tagged 9.1.1.0 at fe84e89: https://git.io/vr05g
grs has quit [Ping timeout: 250 seconds]
<GitHub44> [jruby] nirvdrum pushed 1 new commit to master: https://git.io/vr0Fk
<GitHub44> jruby/master fe84748 Kevin Menard: [Truffle] Fixed the 'jt test tck' command to work with changes made elsewhere to maven.
momomomomo has joined #jruby
<nirvdrum> headius: Indeed. And sorry for the slow replies. I'm trying out a new dev setup that pushes IRC to a different workspace. I don't think notifications are working quite the way I'd like.
<headius> no problem
grs has joined #jruby
momomomomo has quit [Ping timeout: 250 seconds]
<GitHub122> [jruby.github.io] enebo pushed 1 new commit to master: https://git.io/vr0NT
<GitHub122> jruby.github.io/master 9e4f987 Thomas E. Enebo: Update for release
dinfuehr_ has quit [Quit: dinfuehr_]
<lopex> headius: why do they have explicit deps for joni/jcodings there ?
<GitHub46> [jruby.github.io] enebo pushed 1 new commit to master: https://git.io/vr0Nh
<GitHub46> jruby.github.io/master 09e0dc9 Thomas E. Enebo: Change title in downloads to proper release
<enebo> holy crap snake…a 3115 line pom.xml…lopex you are impressed by the wrong stat
<lopex> enebo: lol
<lopex> oh, they use joni separately
<lopex> enebo: wrt that missingisUTF8
ChanServ changed the topic of #jruby to: Get 9.1.1.0! http://jruby.org/ | http://wiki.jruby.org | http://logs.jruby.org/jruby/ | http://bugs.jruby.org | Paste at http://gist.github.com
brauliobo has quit [Ping timeout: 260 seconds]
<GitHub167> [jruby] nirvdrum pushed 1 new commit to master: https://git.io/vr0pK
<GitHub167> jruby/master 13b6bb6 Kevin Menard: [Truffle] Removed code that should have already been deleted.
<GitHub107> jruby/master dea6cd8 Thomas E. Enebo: Update version for next dev cycle (yeah good job Tom)
<GitHub107> [jruby] enebo pushed 1 new commit to master: https://git.io/vr0pS
elia has joined #jruby
elia has quit [Client Quit]
<headius> lopex: yeah, gotta be something like that
elia has joined #jruby
<headius> your library is getting wider use than we realize
brauliobo has joined #jruby
skade has joined #jruby
xenthree3 has joined #jruby
xenthree3 has left #jruby [#jruby]
skade has quit [Client Quit]
fatephd has joined #jruby
<travis-ci> jruby/jruby (master:39db3ee by Thomas E. Enebo): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131506057)
<enebo> yay
fatephd has quit [Quit: (null)]
subbu|meeting is now known as subbu|away
yfeldblum has quit [Ping timeout: 240 seconds]
<headius> nirvdrum, chrisseaton, eregon: maybe one of you could look into that jt test that has been failing
donV has quit [Quit: donV]
SynrG has quit [Ping timeout: 252 seconds]
SynrG has joined #jruby
skade has joined #jruby
subbu|away is now known as subbu|meeting
<enebo> lopex: 8.1% barleywine?
<lopex> enebo: yeah, and aromatic hops
<enebo> lopex: sounds really low abv for a baleywine
<lopex> yeah
<lopex> enebo: for the strong ipaish ones I still love that of de molen
<enebo> I somehow got a four pack of this
<lopex> enebo: remember that de molen list sorted by abv ?
<enebo> lopex: yeah
<enebo> lopex: bigger is better to some degree until they all taste like raison juice
<enebo> ignore my spellinfg
<lopex> enebo: how do they call the beers when you up the abv by icing the water from it ?
<lopex> icing away ?
<lopex> they might be 30% then
<lopex> or higher
<nirvdrum> headius: I'll disable for now. It seems a bit flaky.
<headius> ok
<enebo> lopex: I don’t remember the term either
<enebo> lopex: tactical nuclear penguin stuff
<lopex> ah, I guess I know polish term
<lopex> enebo: ^^
<lopex> I tend to use wiki as a dict sometimes
<GitHub107> [jruby] nirvdrum pushed 1 new commit to master: https://git.io/vrEIL
<GitHub107> jruby/master cd4a1e6 Kevin Menard: [Truffle] Temporarily disabled integration test that's only failing in Travis.
bbrowning has quit [Quit: Leaving]
talevy has quit [Ping timeout: 260 seconds]
talevy has joined #jruby
<nirvdrum> I don't like ignoring issues that are reproducible in any environment. It's just strange that Travis seems to be the only one that regularly has problems.
<headius> yeah, it's a weird env
<headius> lots of shared resources...some bad project getting a build at the same time as us could probably cause us to fail
<headius> though I don't know how much sharing of machines they do
<lopex> it must be docker :/
<headius> probably
<lopex> headius: remember hitler and docker ?
<headius> builds run a lot faster in that mode than in the vm mode though
<headius> video?
<lopex> yeah
<headius> hahah
<lopex> and I havent even seen that movie (the fall ?)
lanceball is now known as lance|afk
<headius> Downfall
<headius> it's pretty good
<enebo> “If you have never used docker in production leave the room now”
<lopex> node.js hipsters is also good
<headius> yeah this sums up all my concerns plus a few other good ones
<enebo> curl | sudo bash :)
<lopex> I wonder how this is doing https://www.ottoproject.io/
<lopex> vagrant based
<headius> I don't know what's different but this one says "full version" https://www.youtube.com/watch?v=ihpjq5T7r9Q
<enebo> hahaha “Don’t cry…you can run bash on windows 10 now” very funny version
<headius> yeah, well done
<headius> I'm down from 40s to 24s and caching machines didn't seem to help any of that
<headius> hand-splitting this case/when and making it if/else did most of it
<lopex> how does mri on it ?
<headius> 24s with an unmodified lexer
<headius> hah
<headius> yeah nice
subbu|meeting is now known as subbu
<headius> I must have crossed a threshold where hotspot will actually jit this now
<lopex> maybe the matching itself is slower
<lopex> we miss Sunday Boyer-Moore modification
<lopex> but I dont think it's huge and it only matter for big inputs
<lopex> as we've been always slower for some char classes, cant recall what it was
<lopex> *s/as/and/
<nirvdrum> Here I thought I was the only one that got this worked up about Docker.
<travis-ci> jruby/jruby (master:13b6bb6 by Kevin Menard): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131513493)
fuzzyhorns1 has quit [Quit: Leaving.]
<lopex> unikernels!
<lopex> I need to try nixops though
<lopex> though it's cgroups based too
<nirvdrum> I still can't use Docker and connect to a VPN :-(
blandflakes has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
oblutak has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]
blandflakes has joined #jruby
blandflakes has quit [Client Quit]
<lopex> headius: maybe jruby needs some tweaking for thresholds
<lopex> like new ratio 2:1 works best for me
<headius> could be
<headius> FWIW I modified brakeman to re-run the same command in a loop and we improve to MRI speed or faster after the first run
<lopex> I'd call it success
<lopex> oh, modified
<lopex> headius: does 9.1 emply case/when hash opt ?
<lopex> *employ
<headius> hash opt?
<headius> we have some limited O(1) support for all-fixnum case/when but that's about it
<lopex> they use a hash underneath
<enebo> lopex: this lexer code is all method calls
<headius> lopex: that must be the O(1) optimization
<enebo> lopex: but I bet I could manually speed this up a lot since the lexer uses n overlapping regexps in succession
<headius> enebo: it's worse than I realized
<enebo> lopex: but as a human I can combine those to a single regexp with a capture and ikely speed it up since all the ruby will disappear
<headius> many of these token-creating methods themselves have case/whens with regexp too
<headius> and case/when with regexp still forces a frame
<enebo> headius: but for some branches it could kill the inner nest at least
<enebo> since they are all like > or >> or >= or >>=
<headius> sure
<enebo> I think a specification like this could maybe combine some regexps if it “knew” regexp grammar
<headius> you know I guess I shouldn't be surprised at this point that a 30-40s run is not enough to warm up
<enebo> but the rhs {} actions probably make that much more difficult
<headius> unmodified brakeman improves to 30s from 40+ by the third run
<headius> the actions are all BS
<headius> all action does is yield
<headius> I collapsed all of those in my modification
<enebo> yeah I noticed none of the had captures
yfeldblum has joined #jruby
<headius> so that's at least far fewer dispatches
<headius> I'll show you a diff
<headius> looks like this is holding steady at 30s per iteration now
<headius> MRI is 24
<enebo> wow this defined with colon2 stuff will be a lot more work
<enebo> what happens too if I have A as an aurtoload and then I try and defined?(A::B)
<lopex> headius: and yet mri does more work
<headius> yep
johnsonch is now known as johnsonch_afk
<lopex> it also allocs the stack everytime
skade has quit [Quit: Computer has gone to sleep.]
<lopex> does more preprocessing
<lopex> though DRegexp caching isnt used here since there's /o everywhere
<GitHub17> [jruby] enebo pushed 4 new commits to master: https://git.io/vrEGe
<GitHub17> jruby/master b3fb6e4 Thomas E. Enebo: We need to dedup defined message strings so they all have same id
<GitHub17> jruby/master 7103f60 Thomas E. Enebo: We never returned 'method' in defined? in this helper
<GitHub17> jruby/master 70bdd74 Thomas E. Enebo: defined? should not actually autoload anything
<lopex> headius: is this method compiled into a big bytecode thingy ?
<lopex> or split somewhat ?
<headius> yup
<headius> not split by us
<headius> we don't have method splitting in 9k yet
<lopex> headius: hah, I wonder if you'll use passed jvm threashold to modify you're own
<lopex> when it's there
<travis-ci> jruby/jruby (master:dea6cd8 by Thomas E. Enebo): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131513758)
Aethenelle has quit [Quit: Aethenelle]
<havenwood> added 9.1.1.0 to ruby-install and RVM and saw a PR open on ruby-build
<headius> havenwood: cool, thank you
<headius> lopex: we probably could
<havenwood> no prob, thanks
<lopex> headius: to make those play together
<lopex> but last time I heard hotspot is smarter nowadays wrt heuristics for bytecode / native code sizes
<headius> a little better, but not much
<headius> it still bails out too early in optimization pipeline if things get too big
<headius> graal just eats and eats and eats
<lopex> I wonder what's the reason
<headius> maybe I should try this in graal too
<lopex> it's just numbers
<headius> I can certainly try tweaking thresholds up and see what happens
<lopex> like the piepline has above polynomial complexity
<lopex> or above exponential
<lopex> register allocation ?
<lopex> graph coloring always was
<headius> maybe
<lopex> headius: eats like, doesnt care ?
<headius> yeah
<headius> most of the hotspot folks think that's the right thing to do now
<headius> it may have some metrics for how long it works or something, but it's not code size
<lopex> on graal presentation Thomas said they have in great majority linear scans
tcrawley is now known as tcrawley-away
<lopex> maybe it's the economics, like all the threads playing toghether (execution, gc, compiler, etc)
<lopex> headius: also might be similar thing scala compiler suffers, too many phases
<lopex> oh, I love speculating
<headius> heheh
<headius> scala compiler definitely has that problem
<lopex> I should create a site, "speculation out of my ass"
<GitHub78> [jruby] nirvdrum pushed 1 new commit to master: https://git.io/vrECf
<GitHub78> jruby/master 5804e33 Kevin Menard: [Truffle] JRuby+Truffle is still using the 2.2.0 stdlib.
<lopex> headius: but seriously, intel struggles to create code cache
<lopex> headius: and nobody uses it
<GitHub84> [jruby] headius pushed 1 new commit to master: https://git.io/vrECZ
<GitHub84> jruby/master c4a013b Charles Oliver Nutter: Merge pull request #3896 from jruby/test-new-recursion...
<GitHub161> [jruby] headius closed pull request #3896: Test new recursion (master...test-new-recursion) https://git.io/vrWQq
<GitHub178> [jruby] headius deleted test-new-recursion at dc7c489: https://git.io/vrECn
<headius> I should do some testing with the new recursion guard...could be much more efficient
<lopex> spaculative ?
<lopex> *speculative
<travis-ci> jruby/jruby (master:cd4a1e6 by Kevin Menard): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131526259)
Aethenelle has joined #jruby
<headius> I'm being speculative at least :-)
enebo has quit [Quit: enebo]
norc has quit [Read error: Connection reset by peer]
<travis-ci> jruby/jruby (master:3eb736a by Thomas E. Enebo): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131539922)
brauliobo has quit [Ping timeout: 252 seconds]
<GitHub79> [jruby] chrisseaton pushed 10 new commits to master: https://git.io/vrEu7
<GitHub79> jruby/master da2af75 Chris Seaton: [Truffle] Combine bootstrap and common bignum.
<GitHub79> jruby/master fa37a40 Chris Seaton: [Truffle] Combine bootstrap and common channel.
<GitHub79> jruby/master 5947277 Chris Seaton: [Truffle] Combine bootstrap and common symbol.
<lopex> no that much of an OT but this is genius https://www.youtube.com/watch?v=kLmzxmRcUTo
<lopex> like ppl having trouble realizing the dynamics of online code compilation
Aethenelle has quit [Quit: Aethenelle]
<lopex> the profiles might lie to all of us
<GitHub162> [jruby] chrisseaton pushed 1 new commit to master: https://git.io/vrEzM
<GitHub162> jruby/master 0f190b6 Chris Seaton: [Truffle] Move class to core.
<travis-ci> jruby/jruby (master:5804e33 by Kevin Menard): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131545302)
momomomomo has joined #jruby
<GitHub163> [jruby] chrisseaton pushed 2 new commits to master: https://git.io/vrE2f
<GitHub163> jruby/master f899dd5 Chris Seaton: [Truffle] Fix mistake in how we ignore integration tests.
<GitHub163> jruby/master ee1c654 Chris Seaton: Revert "[Truffle] Temporarily disabled integration test that's only failing in Travis."...
<GitHub90> [jruby] tobymurray-nanometrics opened issue #3905: NotImplementedError: symlink unsupported or native support failed to load https://git.io/vrE2k
elia has quit [Quit: Computer has gone to sleep.]
dsferreira has joined #jruby
<GitHub32> [jruby] nirvdrum pushed 1 new commit to master: https://git.io/vrEa7
<GitHub32> jruby/master da7c5c6 Kevin Menard: [Truffle] 'jt test tck' needs to build the maven project, too.
<travis-ci> jruby/jruby (master:c4a013b by Charles Oliver Nutter): The build is still failing. (https://travis-ci.org/jruby/jruby/builds/131545773)
pawnbox has quit [Remote host closed the connection]