<durnoyabsurd>
Hi! Can anyone help me with this example? https://gist.github.com/durnoyabsurd/ff6d8ca61e7355104ff0 I'd like to have a java signature for my constructor because java library i want to use my ruby class with uses reflection to identify if the proper constructor is declared. But this example doesn't work because of "expected a Java class, got Java::MyClass". What am I doing wrong?
yfeldblum has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 2 new commits to master: http://git.io/zLmkYQ
<JRubyGithub>
jruby/master 59c9f74 Charles Oliver Nutter: Revert "expand path before adding it to the $CLASSPATH variable"...
<JRubyGithub>
jruby/master b555717 Charles Oliver Nutter: Revert "get the $CLASSPATH variable right and allow proper URL as well"...
JRubyGithub has left #jruby [#jruby]
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<JRubyGithub>
[jruby] mkristian opened issue #2277: become_java classses are not in general part of Thread.current_thread.getContextClassLoader http://git.io/0hnZOQ
JRubyGithub has left #jruby [#jruby]
elia has quit [Ping timeout: 252 seconds]
towski has joined #jruby
pchalupa has quit [Quit: Computer has gone to sleep.]
brettporter has quit [Remote host closed the connection]
<JRubyGithub>
[jruby] mkristian created redefine-uri-classloader-meaning (+2 new commits): http://git.io/V_p-Vg
<JRubyGithub>
jruby/redefine-uri-classloader-meaning b672b80 Christian Meier: redefine uri:classloader: meaning to be the parent classloader of runtime.getJRubyClassLoader...
<JRubyGithub>
jruby/redefine-uri-classloader-meaning 99ff77d Christian Meier: add testcase for the case where jruby.home is inside a jar but not on the context-classloader
deobalds has quit [Quit: Computer has gone to sleep.]
brettporter has joined #jruby
josh-k has joined #jruby
robbyoconnor has quit [Quit: Konversation terminated!]
robbyoconnor has joined #jruby
elia has joined #jruby
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian force-pushed redefine-uri-classloader-meaning from 99ff77d to 0a3feed: http://git.io/cwP5fQ
<JRubyGithub>
jruby/redefine-uri-classloader-meaning 5fbdff9 Christian Meier: redefine uri:classloader: meaning to be the parent classloader of runtime.getJRubyClassLoader...
<JRubyGithub>
jruby/redefine-uri-classloader-meaning 0a3feed Christian Meier: add testcase for the case where jruby.home is inside a jar but not on the context-classloader
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian closed pull request #2271: refactor FileResource.inputStream to be easier to use (jruby-1_7...FileResource.inputStream) http://git.io/Z4zLng
JRubyGithub has left #jruby [#jruby]
elia has quit [Quit: Computer has gone to sleep.]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian opened pull request #2278: Redefine uri classloader meaning (jruby-1_7...redefine-uri-classloader-meaning) http://git.io/kxA0Mg
JRubyGithub has left #jruby [#jruby]
theurich has joined #jruby
josh-k has quit [Remote host closed the connection]
josh-k has joined #jruby
rsim has joined #jruby
brettporter has quit [Remote host closed the connection]
josh-k has quit [Remote host closed the connection]
rsim1 has joined #jruby
mister_solo has joined #jruby
rsim has quit [Ping timeout: 265 seconds]
frobs has quit [Read error: Connection reset by peer]
erikhatcher has joined #jruby
shellac has joined #jruby
triple_b has joined #jruby
subbu has joined #jruby
<headius>
chrisseaton, eregon: that failure is in truffle language specs
mister_solo has quit [Ping timeout: 264 seconds]
kelcecil has joined #jruby
subbu has quit [Read error: Connection reset by peer]
<eregon>
headius: I'll check
<headius>
I'm on mobile so hard to few build results
<headius>
view
subbu has joined #jruby
<headius>
I am Buildcop
<eregon>
sounds like sonething I introduced, sorry
anaeem1 has joined #jruby
<headius>
np...I know we've had a lot of red builds, but they *should* be green now, so watch for failures
<eregon>
headius: BTW, I'd be quite interested if you can tell me about the build process and the JRuby annotation processor one of these days
<eregon>
OK!
<headius>
whenever you like
<headius>
it could use a reboot, but it has served us well for 6ish years
<headius>
the annotation stuff
<chrisseaton>
headius: do all your core methods use the annotation processor to find methods? Playing with AOT I think I can still see some stuff loaded using reflection.
<headius>
they all do, but any that aren't generated AOT use reflection to generate at runtime
<headius>
they won't use reflection to dispatch without a flag, and I don't even know if reflective invokers are still working 100% right
ryez has joined #jruby
nirvdrum has joined #jruby
mitchellhenke has joined #jruby
<headius>
most (probably all) exts don't generate invokers ahead of time, for example
lance|afk is now known as lanceball
<headius>
I always meant to get a nice ant/maven plugin to generate invokers but never got around to it
subbu has quit [Read error: Connection reset by peer]
<chrisseaton>
headius: it looks like even with the annotation processor, everything still needs to go through a Class.forName at some point
<headius>
well, how else would you load classes dynamically?
codefinger has joined #jruby
<chrisseaton>
but why do you need to load them dynamically? can't the source generator in the annotation processor create factory methods to create instances for you?
<headius>
the invoker generator checks first to see if that invoker has already been generated, using a specific format for the name
<chrisseaton>
headius: ah so the generated code is used like a kind of cache
<headius>
not checking would mean linkage errors which are much more expensive than a forName check
mitchellhenke has quit [Client Quit]
<chrisseaton>
'do we have generated code for this, otherwise find methods using reflection'
<headius>
something like that
subbu has joined #jruby
<headius>
reflection is used to walk annotations in the given class because there's no other way
<headius>
the Populator classes avoid that in AOT
<headius>
and then invoker generation uses reflection to see if there's already a class for the given set of annotations
<headius>
every annotated class in core/ should get pre-generated populators and invokers, and should have no reflection involved
<headius>
if that's not the case I want to know it
<chrisseaton>
the best thing about AOT (Truffle's or any other approach) is going to be setting the core library object graph at compile time
<chrisseaton>
that and a compiled parser
<headius>
yeah, I'm sure we could do a better job of that in jruby proper, but it really would only help boot time, and loading all the annotated classes is a small fraction of base startup
<headius>
compiled parser would be a huge help for us
<chrisseaton>
headius: what's the biggest fraction? I think you said byte code verification once
<headius>
for base startup it's reflection-based loading of Java proxy classes
<headius>
that takes 30-50% of jruby -e 1
<headius>
mostly because a lot of classes have to be walked to bind the few we need at boot
<nirvdrum>
In real world applications, openssl gets required on virtually every startup and that dominates most other things in my experience :-/
<headius>
it would be worthwhile to get openssl generating invokers and populators
subbu has quit [Read error: Connection reset by peer]
<chrisseaton>
yeah nirvdrum was talking about that - I think he worked out it was extremely eager in loading all cytpo algorithms
bbrowning_away is now known as bbrowning
<headius>
ahh
<headius>
yeah, that *might* be better with pregen, since reflective binding of an annotated class triggers a lot of loading and linking that might be deferred
<nirvdrum>
And it happens just by virtue of require 'openssl', regardless of whether you actually invoke anything in there.
<headius>
pregen would be my first step
subbu has quit [Read error: Connection reset by peer]
<nirvdrum>
How would that help here? Save the time looking up providers?
<headius>
nirvdrum: so I assume it was generation, loading, linking all those modules' methods dynamically that was the problem?
<nirvdrum>
I think a lot of it just front-loaded computation.
<nirvdrum>
Including at least one source from /dev/random, which blocks.
subbu has joined #jruby
mkristian has joined #jruby
subbu has quit [Read error: Connection reset by peer]
<headius>
well if there's no pregenerated populators, it uses reflection to walk the annotated class
<headius>
if there's no pregenerated invokers, it generates and loads classes at boot
<headius>
ouch yeah...403 methods
<headius>
that could probably be made lazy if it's still there
subbu has joined #jruby
<nirvdrum>
And tangential to this, it may make sense to revisit the idea of using /dev/random by default. While it's what the JVM does and it is overridable, it's not what MRI does. There's an issue open that says this really messes with people in KVM environments because all VMs share the same source of entropy.
<headius>
looks like -ropenssl adds about 1.5s to startup with --dev
dabradley has quit [Ping timeout: 245 seconds]
<headius>
nirvdrum: what does MRI use by default? I forget
triple_b has quit [Read error: Connection reset by peer]
triple_b_ has joined #jruby
<headius>
invokedynamic-based invokers reduces that 1.5s to 1.2ish
<nirvdrum>
Whatever OpenSSL does. I don't recall, but I think it was /dev/urandom.
<headius>
on many systems urandom and random are the same
<nirvdrum>
But on Linux in particular they're not.
<headius>
yeah just confirmed...darwin they're the same, and maybe on other BSDs
<headius>
using random on linux should actually be better because it won't return results with exhausted entropy
<headius>
so I guess I'm confused what the issue is
<nirvdrum>
BSD they're the same because the OS takes care to properly seed it at boot. Linux doesn't, but every distro under the sun compensates for that. But because there's a very small window where you may request a random number immediately after boot and before /dev/urandom has been seeded, everyone uses /dev/random as the default and it blocks.
<headius>
but /dev/random will block if its internap entropy pool has been exhausted
<headius>
internal
<nirvdrum>
My understanding is once /dev/urandom is seeded it's as cryptographically secure as /dev/random is.
<chrisseaton>
some expert wrote an article about random and urandom recently that dispelled a few myths - can't remember where though
<headius>
if it's the blocking that's a problem, we can certainly consider that, but random should be as good or better than urandom, so I don't get the kvm issue
subbu has quit [Read error: Connection reset by peer]
<headius>
if they're provably equivalent as far as crypto goes then there's no reason not to use urandom
<headius>
so...need input
<nirvdrum>
Aethenelle's boss wrote a good article on it. I can't find it at the moment.
subbu has joined #jruby
<headius>
we decided on /dev/random both because it was what Java used and because it was the safer option, crpyographically, given the entropy pool stuff
<nirvdrum>
Every time you create a Random in the JVM, it reads from /dev/random by default. That can block. If you're on a single machine with a lot of VMs (i.e., most hosting providers), you can thrash.
<headius>
this is a nice post, but I don't see any proof
<headius>
the epilog there mentions that MRI actually prefers the prng in OpenSSL before going to urandom
<nirvdrum>
But the MRI one is still a CSPRNG. It doesn't read from /dev/random. The article is advocating for two things: don't use /dev/random and then don't try to recreate /dev/urandom in your own code.
anaeem1 has quit [Remote host closed the connection]
<nirvdrum>
As for proof . . . I'm not sure how you prove it. But the author is the dude from Matasano Security and it was peer-reviewed by a security professor at Johns Hopkins. Both are widely respected in the field.
subbu has quit [Read error: Connection reset by peer]
subbu has joined #jruby
subbu has quit [Read error: Connection reset by peer]
<headius>
well, there's various tests for the quality of random data...something empirical would be nice
<headius>
rather than just a peer-reviewed "The docs are lying" assertion
<headius>
I'm not trying to be a spoiler, but I don't want to change back and forth between random and urandom every six months :-)
<headius>
we couldn't get a definitive answer last time and this is not a definitive answer (to me) right now
<nirvdrum>
This is the same data we used the last time :-P
<headius>
and we went with random anyway
e_dub has joined #jruby
<headius>
but I'm also not lazy...so I'll contact this guy
<nirvdrum>
Sorta. We mitigated the problem so we didn't think it mattered any longer.
<lopex>
diehard tests
<nirvdrum>
And we mitigated the problem by caching a single instance of SecureRandom per thread.
anaeem1_ has joined #jruby
<lopex>
mri still uses MT ?
<headius>
to be clear...we mitigated the runtime issues going to random for every number, but left in place the boot-time issue that we have to make a blocking kernel call
<nirvdrum>
So we weren't whacking /dev/random every time we want a UUID.
<headius>
lopex: MT?
<lupine>
hmm, I'm having trouble resolving addresses with Resolve::getaddresses() on a machine with only-v6 connectivity
<nirvdrum>
Correct. I think we were all satisfied at the time to reduce the likelihood of blocking due to excessive /dev/random reading within your own app.
<lopex>
headius: mersenne twister is not crypto secure
<nirvdrum>
For me, the problem largely went away.
<headius>
lupine: you may be the first person I've met using JRuby on an only-v6 system
<lopex>
if it still uses that
e_dub has quit [Client Quit]
<nirvdrum>
But I can see in the VPS case how this could still be problematic.
<lupine>
headius, and maybe the last :D
deobalds has joined #jruby
<lupine>
it works in YARV, anyway
<headius>
lupine: there is a JVM property I believe we set that makes the JVM prefer ipv4 addresses
<nirvdrum>
For $5, I can effectively DoS app on DigitalOcean :-P
<lupine>
ugh
anaeem1_ has quit [Remote host closed the connection]
<lupine>
presumably I can reset that?
<headius>
that's what I'd try
<nirvdrum>
headius: I'd ping Aethenelle when he shows up. I'm pretty sure he's at Matasano.
<lupine>
Djava.net.preferIPv4Stack ?
<nirvdrum>
And/or kares.
<headius>
nirvdrum: definitely
<headius>
lupine: yeah, that one
<headius>
if we're not setting that, then there are other properties to tweak Java into using v6 for everything
<headius>
tl;dr: we don't do anything special in JRuby for v4 vs v6, so it is more likely to be a JVM config thing
<lupine>
this needs a bug against it something :D
<headius>
indeed!
<lopex>
headius: what's the best way to profile cold code now ?
<headius>
lopex: like profiling startup?
<lopex>
headius: yeah, actually it's for reloading, every time in dev mode I'm reloading a code that takes some time
brettporter has joined #jruby
<headius>
I use --sample/-Xprof, but it's mostly good for finding really bad stuff
<headius>
not particularly accurate
<lopex>
yeah I remember
<headius>
those are always on and dump on exit, though
<lopex>
and I dont care about hot perf at all
<lopex>
:)
<headius>
heheh
<lopex>
since it's on startup thingy
<lopex>
I know, rare case
<lupine>
hmm, jruby -J-Djava.net.preferIPv4Stack=false -e 'require "resolv" ; puts Resolv::getaddresses("google.com")' isn't doing the trick all by itself
* lupine
hunts for other flags
<headius>
lupine: it raises error?
<headius>
or returns nothing
<lupine>
it just hangs forever
<lupine>
tcpdump shows dns requests being made and getting A and AAAA records back in a loop
<headius>
oh, that's weird
<headius>
hmm
brettporter has quit [Ping timeout: 260 seconds]
<enebo>
do we use any jnr-* stuff for networking now?
<headius>
hmm, I don't see anything in resolv.rb that would loop forever
<headius>
lupine: ctrl+\ or jstack command will get a thread dump you should include in your bug
<nirvdrum>
enebo: How do you feel about setting the source location for the BlockNode containing PreExe19Nodes to the source position of the first PreExe19Node in that block?
<headius>
lupine: if possible I'd love for us to work without any property-tweaking, but if properties don't help then we probably do have a bug (and will need your help with it)
<lupine>
ah, ok. it's not forever - just a very, very long time
<headius>
lupine: very interesting
* lupine
has just had one come back. looks like this:
<lupine>
Resolv.getaddress("auth.bytemark.co.uk")
<lupine>
=> ERROR: #<Resolv::ResolvError: no address for auth.bytemark.co.uk>
<headius>
resolv.rb does explicitly try A and then if v6 is enabled AAAA
<lupine>
jruby --properties doesn't seem to list anything relevant
<enebo>
nirvdrum: pre exe can be anywhere in the BlockNode though right?
<headius>
lupine: no, wouldn't be there
<headius>
I'm looking for the other properties
<lupine>
yeah. the first thing I tried was a monkey patch to make v6 go first
<enebo>
nirvdrum: oh wait let me generate an AST to make sure I am on even footing :)
<headius>
there's that
<lupine>
aye, I gave that a go and it made no difference. maybe setting them on the command line isn't good enough?
<headius>
how did you set them?
<enebo>
nirvdrum: yeah that seems reasonable
<headius>
should be like jruby -J-Djava.net...
subbu has joined #jruby
<nirvdrum>
enebo: It's my first real foray into all this, so I may have it wrong. But I spent several hours tracking down why I had a source position past EOF :-/
subbu has quit [Read error: Connection reset by peer]
<lupine>
yep. this is my test case: jruby -J-Djava.net.preferIPv4Stack=false -e 'require "resolv" ; puts Resolv::getaddresses("google.com")'
<headius>
lupine: did you try the v6 property above?
<enebo>
nirvdrum: that block node is artificial and not lexical so in a sense it should not affect execution but you are doing some IDE support stuff for Truffle?
<headius>
I don't expect it to help since these docs claim it will try v6 if necessary anyway
<lupine>
I did, and I've just run it again to be sure. same outcome
<headius>
lupine: ok, thank you
<headius>
then we may have a gap in JRuby here, possibly forcing ipv4 use somewhere in socket subsystem
<headius>
enebo: unix sockets :-)
<nirvdrum>
enebo: Every node in Truffle has a corresponding source section. I think it's used for things like the debugger. But in any event, Truffle does some verification and will raise an exception if you give it an invalid source.
subbu has quit [Read error: Connection reset by peer]
<nirvdrum>
That currently sets the position for the BlockNode to line 1, offset 18.
<enebo>
nirvdrum: are you sure this is the right method?
<enebo>
nirvdrum: This sets block for all root nodes
<nirvdrum>
enebo: It returns early if there are no begin nodes.
<lupine>
headius, the backtrace I've got times out at /usr/lib/jruby/lib/ruby/1.9/resolv.rb:1021:in `resolv'
kgerman has joined #jruby
<enebo>
It uses the position of the BEGIN and I think that might be wrong?
<lupine>
well, some other gubbins on top, but that's the important line I gues
subbu has joined #jruby
<nirvdrum>
enebo: Well, what I'm seeing is it uses the position for whatever it thinks the next node in the file would be. But the file has been exhausted.
subbu has quit [Read error: Connection reset by peer]
<enebo>
nirvdrum: your example shows me it is set to 0
<headius>
enebo: I don't see anything yet...why do you ask?
<nirvdrum>
So that source position is both wrong and invalid.
<headius>
re socket + jnr
<enebo>
headius: oh just wondering in case we are calling get family or something in jnr and hardcoding to ipv4 struct
<headius>
lupine: that doesn't line up with 1.7 branch, can you show me what line in resolv()?
<headius>
enebo: ahhh
<headius>
no, that all still uses JDK
<enebo>
nirvdrum: You know about -S ast?
subbu has joined #jruby
<nirvdrum>
Nope. I've just been printing out the nodes.
<lupine>
we're still using 1.7.4 in production, it's saying @nameserver_port.each {|nameserver, port|
<headius>
lupine: does it "hang" while consuming CPU or hang quietly?
* lupine
runs watch -n1 pstree -al for the amusement value
subbu has quit [Read error: Connection reset by peer]
subbu has joined #jruby
e_dub has joined #jruby
nerdy has joined #jruby
nerdy has quit [Client Quit]
<headius>
building building building
<lupine>
it's 8G nd 3 cores on SSDs, can't say fairer than that
<headius>
nice
<headius>
twil be a bit for first maven build of JRuby
* lupine
snuggles .deb
<lupine>
the /usr/bin/jruby binary is fairly sane
<lupine>
although I think it might default to 1.8 mode
<headius>
ok
<headius>
I just figured after the fact that I'd go straight to 1.7 branch
subbu has quit [Read error: Connection reset by peer]
<headius>
incidentally, have you tried newer than 1.7.4?
<lupine>
no, I guess I probably should
<lupine>
packaging it got very difficult somewhere after 1.7.4, which is why we've not moved yet
<lupine>
(or more accurately, the debian/ directory I stole stopped working)
<headius>
ah
<headius>
I thought there were still 1.7 .debs being maintained
subbu has joined #jruby
<headius>
just discovered our bootstrapping build requires make + gcc, so that's good to know
<headius>
I guess I knew that, but it's not in docs
Aethenelle has joined #jruby
<headius>
ugh, g++
<headius>
getting there
pchalupa has joined #jruby
kelcecil has quit [Quit: kelcecil]
<headius>
lupine: reproduced
<headius>
with 1.7 head
<lupine>
hurrah :)
subbu has quit [Read error: Connection reset by peer]
brettporter has joined #jruby
<headius>
sidebar: am I the only one that has alignment problems at the command line when I ^C a process? I added a \n to my PS1 explicitly to avoid that
<JRubyGithub>
jruby/master 3e4e479 Thomas E. Enebo: Fix position info for rootnode and highest block node in presence of only BEGIN nodes
JRubyGithub has left #jruby [#jruby]
<enebo>
nirvdrum: I just pushed a fix to the positioning info we were talking about. It might not help the detailedposition stuff but it was definitely wrong
<nirvdrum>
Cool. It looks like you made the change I was going to pile on top, too.
<nirvdrum>
Thanks!
codefinger has quit [Quit: Leaving...]
subbu has quit [Read error: Connection reset by peer]
<nirvdrum>
enebo: Is that worth backporting for 1.7? I'm guessing not.
subbu has joined #jruby
<enebo>
nirvdrum: not really. I am only doing it for you so that truffle can more easilt rely on the info. Root and top Block node cannot generate an error/exception so their start line does not matter for execution
subbu has quit [Read error: Connection reset by peer]
<nirvdrum>
Well, thank you. It's appreciated.
* rtyler
waves
mister_solo has quit [Ping timeout: 250 seconds]
<enebo>
nirvdrum: np
subbu has joined #jruby
subbu has quit [Read error: Connection reset by peer]
<headius>
rtyler: good morning!
<headius>
nirvdrum: this thing I'm debugging for lupine is blocking in SecureRandom :-P
<nirvdrum>
I really wish I understood crypto better. I'm with you. I generally default to the slower thing if there's less likelihood of me screwing it up.
<rtyler>
I was supposeed to build and test something
<headius>
Aethenelle: wanna help us with a crypto question?
<Aethenelle>
sure
<Aethenelle>
sup?
<headius>
we were looking over your boss/friend's post on random vs urandom
<headius>
considering trying to get our SecureRandom to just use urandom, at least for initial salt
<headius>
seed whatever
<Aethenelle>
headius: on that sidebar: no, you're not the only one... though, I don't modify PS1 generally...
<headius>
I'm not a crypto guy
<headius>
the post is good but there's no empirical evidence that anything it says is true
<headius>
Aethenelle: for my PS1 I previx \n so that ^C doesn't shift the CLI over
<headius>
got sick of typing over the wrong thing
benlovell has quit [Ping timeout: 264 seconds]
<Aethenelle>
okay... now I know the post... I'll have to refresh my memory on Java source code... pretty sure on using systems it uses /dev/random to seed SHA1PRNG by default, so as long as you don't seed it with something bad (timestamp), you'll be good.
josh-k has joined #jruby
<Aethenelle>
on windows... I know it uses a thread based random seed because the windows native one is "too slow"
<Aethenelle>
... now to go fetch code an read... gimme a few...
<mkristian>
```System.load(file);file.delete();``` can that go wrong, so far I was able to test things it works
<headius>
you may remember a few months back we went around and around on this and eventually settled on using the SHA1PRNG from JDK, which initially seeds from /dev/random, but nirvdrum pointed out that causes contention when you start up many instances on a single machine
<headius>
mkristian: I don't understand
<Aethenelle>
on most systems /dev/random is a link to /dev/urandom which is a PRNG and no longer relies entirely on available entropy
<headius>
lupine: so I'm seeing it do all the A requests first, and slowly time out, and then the AAAA requests, and slowly time out
<lupine>
yeah
<nirvdrum>
Aethenelle: I think we're dealing with Linux specifically here.
<Aethenelle>
as long as the system has a chance to warm up for a bit /dev/urandom isn't going to give you realistic problems... which is really only a minor concern and only on virtual systems...
<lupine>
wonder if it's probing the IPs to see if they're up
* lupine
can check that
<Aethenelle>
on linux that'd require combing the kernel source... the man page seems outdated (hopefully)
<headius>
lupine: do the DNS hosts have reverse addresses?
mkristian has quit [Ping timeout: 250 seconds]
<lupine>
yep. /etc/resolv.conf - 2001:41c8:2::1 and 2001:41c8:2::2 - dnscache{1,2}.bytemark.co.uk
<Aethenelle>
it appears the man page isn't out of date...doesn't the Ruby SecureRandom just use the Java SecureRandom impl?
diegoviola has joined #jruby
<lupine>
is a line request/response as tcpdump sees it
<headius>
yeah this may not be v6 versus v4 at all
<lupine>
matching ports and request ids
<headius>
maybe something v6 + udp that's weird
<lupine>
can we force it to tcp, see if it works?
noop has joined #jruby
<headius>
oh, good call, I think we can
<lupine>
the nameservers do support tcp
<lupine>
I love our infra sometimes :)
<Aethenelle>
headius: what exactly are the options you're looking at? java's SecureRandom vs /dev/urandom?
<headius>
Aethenelle: well, the research we did before was figuring out what Java does by default for SecureRandom, because it has a few different RNG options
<headius>
we eventually decided to use a cached SHA1PRNG instance that's seeded from /dev/random
<headius>
but the question now is whether we should use that and seed from /dev/urandom
<headius>
to avoid the block
noop has quit [Client Quit]
<Aethenelle>
i'd either leave it to java and seed from java's SecureRandom or directly seed from a native source (urandom or whatever window's is) with a failover to java's SecureRandom
<headius>
lupine: works with TCP
<lupine>
excellent
<headius>
so it's v6 + udp doing something weird
<headius>
or just udp doing something weird, perhaps
mkristian has joined #jruby
<headius>
given that we haven't had any resolv bugs reported, I'm going to say it requires v6 to repro
<lupine>
I note there's both ConnectedUDP and UnconnectedUDP requestor subclasses, I'm not clear on which is being used
<headius>
I think it's Unconnected...I could try forcing Connected
<lupine>
might narrow it down. this code isn't particularly clear to me at the moment
<headius>
it's pretty dense
<headius>
but I don't know dns prototcol at all
<lupine>
all I can think is that @socks doesn't contain the socket it should
<lupine>
but that'd be a bit weird
<headius>
connected works
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/k0ZtYQ
<JRubyGithub>
jruby/master f96b667 Kevin Menard: Added a new test for BlockNode position info when wrapping BEGINs.
JRubyGithub has left #jruby [#jruby]
mister_solo has quit [Ping timeout: 264 seconds]
<lupine>
I'm just checking what fds it has open, and it does have the right one open
<lupine>
I say "the right one"
<headius>
lupine: it seems like the main diff between those two UDP is that Unconnected uses @sock.send(@msg, 0, @host, @port) and Connected uses @sock.send(@msg, 0)
<headius>
that seems to align with the theory that the response is coming back to the wrong place
phrinx has joined #jruby
<Aethenelle>
enebo: just got smart... FreeBSD uses libcrypt for crypt(3)... no entry in nm libc.a
<headius>
lovely
<enebo>
Aethenelle: thanks buddy!
<Aethenelle>
np
<enebo>
I am betting netbsd might also
<lupine>
hmmmmmm
<Aethenelle>
i'll let you know in a bit (longer if I have to install anything...)
<headius>
host.index(':') ? "::" : "0.0.0.0"
<headius>
that stuff is all over and seems really gross to me
subbu has joined #jruby
<lupine>
aye, although I'm not convinced it's the problem
<lupine>
blah. have to get gone, I've got a dinner at 5:45 :D
josh-k has quit [Remote host closed the connection]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] enebo pushed 1 new commit to jruby-1_7_16: http://git.io/NaG_ng
<JRubyGithub>
jruby/jruby-1_7_16 8390e62 Thomas E. Enebo: rexml patch
JRubyGithub has left #jruby [#jruby]
<headius>
lupine: ok...file that bug with all info from today when you get a chance
<JRubyGithub>
[jruby] enebo pushed 1 new commit to jruby-1_7: http://git.io/q419Sg
<JRubyGithub>
jruby/jruby-1_7 d569253 Thomas E. Enebo: rexml patch
JRubyGithub has left #jruby [#jruby]
<lupine>
I did create a bug, it's missing the most recent bits about exactly the broken bit of code
<headius>
it seems like the problem is basically doing a send with host/port ends up never seeing the response
phrinx_ has joined #jruby
<headius>
ok
<headius>
I'll add what I've found and drop off your VM for now...we need to come up with an isolated case doing unconnected UDP, send with host/port, and select
<JRubyGithub>
jruby/master aaed4a6 Thomas E. Enebo: rexml patch
anaeem1_ has joined #jruby
<headius>
my connection is dog slow today so this is like hacking over a 2400bps modem
<headius>
enebo: do you see speed drop-offs on your commercial comcast?
<Aethenelle>
enebo: yup, same in netbsd
<headius>
my consumer line has been a dog lately
Hobogrammer has joined #jruby
<enebo>
Aethenelle: cool
<enebo>
headius: nope
<Aethenelle>
I can check solaris but that vms on a different disk so it'll have to be laster...
<Aethenelle>
*;ater
<Aethenelle>
*later
phrinx has quit [Ping timeout: 250 seconds]
<nirvdrum>
I like the word "laster".
<headius>
enebo: I might have to suck it up and do that then
<headius>
and get RHT to pay
<Aethenelle>
headius: I've heard the best way to go on comcast (assuming you don't need cable too) is business... better support, bandwidth and price usually
e_dub has quit [Quit: e_dub]
<headius>
yeah
<headius>
I just didn't want to pay the extra compared to residential
<headius>
we don't have cable cable
<headius>
just internet
<Aethenelle>
unfortunately for me i have a strong dislike for comcast... especially since they tried to bill me for services rendered after my cancellation... they eventually "forgave" the debt
<Aethenelle>
uverse has it's own capacity problems that comcast doesn't really have...
mkristian has quit [Ping timeout: 240 seconds]
<headius>
I don't have a lot of options
<headius>
DSL is a complete non-starter now
<Aethenelle>
if you need to get something done w/ support (at least for the consumer side) ask to speak w customer retention
<headius>
good tip
<Aethenelle>
you talked to uverse? it's acutally dsl2... fiber to somewhere down the block-ish then phone from there...
mister_solo has joined #jruby
<headius>
I'm trying to look it up now but my connection is too slow
<headius>
not in service area for ATT
<Aethenelle>
you have any other services from comcast?
<headius>
we're Qwest up here
<headius>
they might have newer, better DSL, I dunno
<Aethenelle>
i didn't realize qwest was still out there...
<headius>
comcast does business lines...enebo has one
<headius>
oh, I mean CenturyLink
<headius>
but yeah, no ATT
<Aethenelle>
you take a look at the stats on your cable modem?
<Aethenelle>
192.168.1.100 iirc
<Aethenelle>
what's the snr and up/down stream power thingy
<Aethenelle>
... or are you looking to switch to comcast from qwest and I completely missed something?
<headius>
I have comcast now and I'm looking to have a less shitty connection
<headius>
trying to get to router...I think I changed the default IP and can't remember it now :-(
shellac has quit [Quit: Computer has gone to sleep.]
<nirvdrum>
Check your gateway settings for your connected device?
<headius>
traceroute looks like pings get long well into comcast infra
<headius>
9 as15169-2-c.350ecermak.il.ibone.comcast.net (66.208.233.142) 394.877 ms 890.795 ms 1111.189 ms
<headius>
everything's sub-100ms up until that
<headius>
so maybe today is not my local connection's fault
<headius>
hah, ord31s21-in-f0.1e100.net
<headius>
1e100.net
<headius>
google
<headius>
cute
<Aethenelle>
my dad had (he's switched to uverse) a problem w/ comcast having old cables in his area... i have no idea how many times we had alternating line techs and inside tech before we emailed execs and copied the city...
mkristian has joined #jruby
<Aethenelle>
each tech would say we needed the other kind... we eventually got a cable or two fixed but they never resolved it entirely before i moved out and my dad never followed up on it.
<headius>
it *has* been really good up until recently
<headius>
I saw some posts claiming that it often gets slow during the holidays because family comes home to visit
<Aethenelle>
i wouldn't expect that to be an issue... then again i know nohing about the holiday migratory habits of the average person...
towski has quit [Quit: goodbye friends I am gone]
towski has joined #jruby
benlovell has joined #jruby
JohnBat26 has quit [Remote host closed the connection]
benlovell has quit [Ping timeout: 264 seconds]
<Aethenelle>
looks like Java (in 8 at least) is now using the windows native random source...
x1337807x has joined #jruby
mister_solo has quit [Ping timeout: 250 seconds]
<Aethenelle>
okay... I'd just seed off an unseeded java SecureRandom... looks like the defaults are good and it still give the option of overriding with the java.security.egd and securerandom.source properties
r4um has quit [Ping timeout: 264 seconds]
<headius>
have a look at SecureRandomLibrary for what we do now...it will lead you to ThreadContext where we try to force the SHA1PRNG
<Aethenelle>
it'll also work on any platform Java supports because there's a failover to (probably less secure) non native options.
<tarcieri>
_____ ____ ___ ____ _ __ ___ _ _
<headius>
we ended up forcing SHA1PRNG because the default was going back to kernel for every number
<headius>
lots of discussion and analysis there that led us to current config
<Aethenelle>
okay... now I see it... one sec to collect...
brettporter has quit [Ping timeout: 244 seconds]
ederign is now known as ederign_afk
<Aethenelle>
okay... this comes down to usage... the native random sources (w/ the exception of PRNG based ones like BSD and OSX) are really only useful for small amounts of random and are used for seeding another PRNG for generating large amounts of randomish data.
<Aethenelle>
Java's SecureRandom looks like it's actually doing it kinda wrong in that it's using those kernel sources directly for key generation (as far as i can tell, this indirection is annoying).
<headius>
right...native shouldn't be used for high-speed high-volume rands because it will consume all entropy very fast
<headius>
the issue referenced in that blog post said something along those lines
<nirvdrum>
tarcieri: Care to weigh in?
<Aethenelle>
If ruby's SecureRandom is meant to provide large amounts of data then using the native ones to seed a PRNG is the right way to go.
<headius>
MRI uses a PRNG from OpenSSL if available, falling back to /dev/urandom
<headius>
we currently force the use of SHA1PRNG from OpenJDK, which seeds from /dev/random and is PRNG from there on
<Aethenelle>
then SHA1PRNG is the way to go unless you can find a better one like yarrow
<headius>
that was to avoid the overhead of roundtripping to kernel every time
<headius>
if we could get SHA1PRNG to seed from urandom I think we'd be in line with MRI and not have issues with contention for /dev/random on boot
<Aethenelle>
SHA1PRNG isn't the best... as long as Java's impl is not seeded by the user, it'll be safe enough
<headius>
nah, user never sees this
<nirvdrum>
headius: Isn't that what the java.security.egd property does?
<Aethenelle>
there's a system property for that... one sec
<Aethenelle>
nirvdrum: exactly
<headius>
it does, but setting a property to get this is annoying
<tarcieri>
umm
<headius>
and when I tried it, it only actually used urandom in some configurations
<headius>
the logic in there is all wacko
<Aethenelle>
also securerandom.source=file:/dev/random
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<nirvdrum>
tarcieri: Re-discussing using /dev/urandom instead of the JVM's default of /dev/random.
<Aethenelle>
but you may run into problems on systems w/out /dev/random so you'll have to detect that...
<tarcieri>
/dev/urandom is ideal
<headius>
I think I spelled out everything I tried on that issue
purplefox has joined #jruby
claudiuinberlin has joined #jruby
<nirvdrum>
I think the only case I'm aware of /dev/urandom is inferior is if you clone and resume running VMs. But a lot of things can break if you do that.
<Aethenelle>
nirvdrum: it's also possible on a VMs first boot to have less that satisfactory random
<nirvdrum>
Aethenelle: In the clone case, you'd have two machines spitting out the same random values though.
<nirvdrum>
But most people reboot the machine on a clone, I'd think. IPs and such get pretty messed up otherwise.
<Aethenelle>
for the first few values .. possible in the first boot case too
<nirvdrum>
Gotcha.
<Aethenelle>
nirvdrum: yes, if they clone and resume, they should know what they're doing and there's not a lot that can be done if they don't
<nirvdrum>
In practice, I'd expect by the time you can boot the JVM, things would have stabilized. But I have nothing to really back that up.
<bbrowning>
Antiarc: yeah - varnish is the thing raptor should be benchmarking its turbocache against imho
<bbrowning>
show me how your cache is better than the other caches
robbyoconnor has joined #jruby
robbyoconnor has quit [Client Quit]
<Antiarc>
(Spoiler: Varnish will win)
<bbrowning>
heh
<bbrowning>
I didn't show it there, but for a while I didn't realize raptor was caching the rack hello world responses
<enebo>
Antiarc: I am old school and prefer Tung or Linseed
<bbrowning>
so I had a moment of "man this thing is really fast" and was chasing it down with TB4
<bbrowning>
I ended up getting TB4 only 25% slower than Raptor with Raptor's turbocache enabled on that hello world benchmark
<Antiarc>
enebo: I had a "oh man, I've never heard of those, time to read up" moment before I realized what you meant
<bbrowning>
so even with raptor's caching it's not THAT much faster ;)
<bbrowning>
the ah-ha moment for me was seeing raptor's 8 JVM processes using almost 0% CPU and the PassengerAgent or whatever use about 500%
<bbrowning>
vs my TB4 process that was using 790% of my 800% available CPU
<bbrowning>
then you can inspect the responses under load and see they add a Age: header to all cached responses. You can also verify by returning a dynamic instead of static response and watch the responses from raptor get cached
<enebo>
Antiarc: I just refinished something with some 100% pure Tung oil so it is still on my mind
<bbrowning>
lopex: and their "hello world" was actually just a body of "hello" so almost no body to encode
<enebo>
oh 64
<lopex>
bbrowning: and other http header string overhead ?
errstr has joined #jruby
<lopex>
whatever there is ?
<lopex>
enebo: 64 ?
<enebo>
lopex: 64 people rated it
<enebo>
lopex: which is pretty small sample
<lopex>
enebo: well, it's a polish beer
<bbrowning>
lopex: There definitely is some overhead for TB specifically because undertow converts bytes to strings for its HTTP request / response stuff and then we have to convert back to bytes to handoff to JRuby
<bbrowning>
It's an area where we can improve some if we can figure a way to get the raw bytes from undertow without any java strings in the middle
<lopex>
enebo: drank taht an hour ago
<enebo>
lopex: yeah the polish craft beer scene is pretty great
<bbrowning>
lopex: but, outside of hello world, the execution speed of ruby itself takes up way more time than this stuff
<lopex>
belgian smells indeed
<enebo>
lopex: I had a on of them earlier this year
<enebo>
ton
<enebo>
lopex: not the belgian tripel though
<lopex>
enebo: it's a revolution here, but only since they saw american/new zealand hops
shellac has joined #jruby
<lopex>
enebo: that one is real experiment
<enebo>
lopex: yeah a lot of importing of US hops (which I like)
<lopex>
enebo: which I like
<enebo>
lopex: but I had some american ipas with non american hops which were great still
Aethenelle has joined #jruby
<lopex>
enebo: I learnd about that a year ago
<enebo>
lopex: polish made am. ipa
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/IvX1eg
<JRubyGithub>
jruby/master 8e54c7d Chris Seaton: [Truffle] Make $_ thread local and use it in implicit matches.
JRubyGithub has left #jruby [#jruby]
<lopex>
bbrowning: hmm, I guess it depends how much of the http processing is too eager
<lopex>
bbrowning: and the jruby lazy encoding thingy
<lopex>
bbrowning: does it work ?
<lopex>
like: taint with original response untill any conversion needed
<Aethenelle>
undertow converts http to Strings in Java?!?
<Aethenelle>
that's not good
<lopex>
enebo: and that beer is realy cheap here
<enebo>
lopex: all beer is cheap in poland
<lopex>
oh well, for you :)
<enebo>
lopex: I even bought a westvlettern 12 in Poland for like 12 USD which is like 18EU in Amsterdam
<lopex>
enebo: but you have to be aware where to loop for craftmensbeer here
<lopex>
really
<lopex>
*look
<enebo>
lopex: I am aware of where to look anywhere on the planet
<lopex>
in the Us I heard it's pletiful
<bbrowning>
lopex: We are quite lazy, even though Rack makes that hard. We wait on converting all rack environment values from Java or bytes to Ruby strings until they're needed
<lopex>
hah
<bbrowning>
so if a client sends lots of request headers but the app never needs them then we don't bother to take that conversion penalty
<lopex>
bbrowning: and the old hashcode issue still valid ?
<lopex>
bbrowning: afaik it was very hot complex method (the impl of MRI String#hash)
<bbrowning>
lopex: ahh - yeah we get around that and similar things by being lazy
<bbrowning>
of course if something is needed then we take that hit, but so do other servers
<bbrowning>
there are some hot complex methods but a lot of them appear to be unfortunately necessary complexity
<bbrowning>
ie String#hash
<lopex>
enebo: yeah, and poles are the fourth at drinking beer, and yet all they drink is enterprise drinking :)
<lopex>
enebo: maybe in EU
<enebo>
lopex: “enterprise drinking” (B2EE)
<lopex>
bbrowning: that method deopts easily
<lopex>
in jruby's case
<enebo>
lopex: I think it will change fast though. There were two popular craft beer bars in center of Krakow and all the other bars were near empty in comparison
<bbrowning>
speaking of drinking - bbiab!
bbrowning is now known as bbrowning_away
<enebo>
lopex: and that is in spite of Polish folks thinking craft beer is expensive
<lopex>
enebo: have you heard about black sahti style ?
<enebo>
lopex: I guess once you get hooked on the variety it is worth it to pay a little more
<enebo>
lopex: sahti from scandanavia
<lopex>
yeah
<enebo>
lopex: I am not sure I have heard black mentioned before
<enebo>
lopex: but I have had some US attempts at it
<lopex>
enebo: recent history of germeny is complicated due to the split
<enebo>
lopex: This is mn brewery which has been in business a long time. Even as a child I remember they sold a bock beer (and no I did not drink beer as a child)
<lopex>
enebo: what's the precentage of say, IPA there ?
<enebo>
lopex: a typical ordinary american IPA is about 6.2-6.4% IIPA is usually 8-11%
<enebo>
some IIPAs are a bit lighter and I tend to like those more now
<lopex>
oh, the IIPA is stronger than the ones here
<lopex>
like 7-9
<lopex>
I love them
<lopex>
enebo: and just guess the prices of US beer here
<enebo>
BJCP says 5-7.5% for IPA but most seem to be in the middle
<lopex>
enebo: 0,7 liter IIPA 12$
<lopex>
insane
<dfr|work>
errr
<dfr|work>
is there a jar in test suite that contains a fooService?
subbu has quit [Quit: Ex-Chat]
<dfr|work>
I see there a DummyService but no tests that use it =/
x1337807x has joined #jruby
<enebo>
lopex: yeah the abv in an iipa can make that an ok deal though
<enebo>
Oh gotta run…meeting up with headius
<enebo>
lopex: fun talking to you…STRANGER
anaeem1_ has quit [Remote host closed the connection]
enebo has quit [Quit: enebo]
<lopex>
stranger
<lopex>
they must be missing me
claudiuinberlin1 has joined #jruby
claudiuinberlin has quit [Read error: Connection reset by peer]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] nirvdrum pushed 1 new commit to master: http://git.io/gY8noQ
<JRubyGithub>
jruby/master c1bf2b6 Kevin Menard: [Truffle] Fixed exception message when boxed primitives are used....
JRubyGithub has left #jruby [#jruby]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] chrisseaton pushed 1 new commit to master: http://git.io/rHgpjA
<JRubyGithub>
jruby/master 6127af9 Chris Seaton: [Truffle] Uniform guards for type.
JRubyGithub has left #jruby [#jruby]
<lopex>
chrisseaton: how far is jruby/truffle wrt string specs ?
ryez has quit [Ping timeout: 246 seconds]
bbrowning_away is now known as bbrowning
<chrisseaton>
lopex: we're concentrating on language specs until they're all done - so we haven't dug into the string core specs yet really
<chrisseaton>
lopex: but strings is one of those areas where we can use a lot from JRuby via ByteList
<lopex>
chrisseaton: ok
<chrisseaton>
lopex: if I sat for a week I'm confident I could clear all the string specs, but that's not what we're focused on at the moment which is why we haven't done it
<lopex>
chrisseaton: and StringSupport from jruby ?
<lopex>
it;s all shady though
<chrisseaton>
lopex: yeah, and in some cases we're abstracting some other string stuff to borrow from JRuby
<chrisseaton>
lopex: as an exercise I went through all the Math specs one day and got 100% of them passing
<lopex>
chrisseaton: cool
<lopex>
chrisseaton: just wondering about what truffle can give like different string method type arguments and the encoding stuff
<chrisseaton>
lopex: and String is one of those classes that I think we'll keep in Java rather than using Rubinius
<lopex>
chrisseaton: since in jruby now it's all interleaved
<lopex>
yeah
<Aethenelle>
i think i saw someone say something about refinements... is that in 9k yet?
<lopex>
definietely
<chrisseaton>
lopex: we get encoding stuff for free with byte list - I haven't encountered any trickiness there yet, and we've got almost all the encoding specs from language working
<lopex>
chrisseaton: like, how much *orphic can truffle callsites be
<Aethenelle>
chrisseaton: most of the truffle stuff uses ruby classes from rbx?
<chrisseaton>
Aethenelle: that's the plan - core library from Rubinius in most cases except where we find a performance reason to do otherwise
<lopex>
chrisseaton: like there's an ut8 encoding class which is being used along ascii one
<lopex>
chrisseaton: and the third one comes along
<lopex>
and now you megamorphize lots of those encoding methods
<lopex>
like 3 is the usual case
<chrisseaton>
lopex: polymorphic call sites is our strongest point - we have a single unified dispatch mechanism that handles normal calls, #send, internal calls (such as implicit to_str or to_i), so a #send with a stable method name is exactly the same as a normal method call. we can also inline arbitrarily large polymorphic call sites.
<chrisseaton>
lopex: we won't megamorphise those, as if something starts to become megamorphic we're likely to 'split' the method at an earlier point - so different copies of the method for different code paths to avoid megamorphic
<lopex>
so specialize early on ? on the call path ?
<lopex>
chrisseaton: just wondering how deep the truffle and as obvious things like encodings have to be intertwined
<chrisseaton>
lopex: if method A contains megamorphic call sites, places that call method A will try to create their own copies of method A, so that they can specialise independently
<chrisseaton>
lopex: a classic example of this is something like Fixnum#+ - that can work with Fixnum, Float, Bignum etc, so places that call Fixnum#+ will often make their own copy of Fixnum# so that it specialises just for the type they're using
<lopex>
chrisseaton: can it still be applied to the lowest encoding bits ?
<chrisseaton>
lopex: it isn't at the moment, but it can be
<lopex>
chrisseaton: or, how much more info oyu need to apply to it via annotations
<lopex>
or at all ?
<chrisseaton>
lopex: it's just like where you have an implicit call to to_str in puts - we use a full dynamic, inlining, splitting, specialising call site for that call, even though it's within our core library implementation - we can do that same thing for encoding
<chrisseaton>
lopex: we don't work on performance stuff unless we have a benchmark to exercise it - is there a benchmark for what you're asking about I can have a look at?
<lopex>
chrisseaton: can you imagine an architecture of a code where jruby and jruby/truffle can benefit from one the most ?
<lopex>
given jruby-non-truffle wont be able to use that ?
<lopex>
I think, there the work would have to split
<chrisseaton>
lopex: JRuby needs hotspot to split methods for it to do that I think
<lopex>
since truffle offers the opportunities
<lopex>
chrisseaton: so same functionalite needed ?
<chrisseaton>
yeah HotSpot needs to do this - headius knows about it and I'm sure he lets the HotSpot people know he needs it - although it could also be simulated in IR, but it's complicated
<chrisseaton>
it sounds like you're asking about something specific - have you got a benchmark?
<lopex>
chrisseaton: nothing specific :)
<lopex>
chrisseaton: but I guess it;s lots of cases
<lopex>
chrisseaton: jcodings contains lots of potentially depoted cllsites at runtime
<lopex>
chrisseaton: lots of points like length(), nextByte() etc plethora
<lopex>
chrisseaton: that's lots of potentially megamorphic hot callsites
<lopex>
chrisseaton: an example
e_dub has quit [Quit: e_dub]
<chrisseaton>
lopex: the Truffle compiler compiles through all that library code, so if a Truffle method is split, all the call sites in JCodings etc can be split as well
<chrisseaton>
obviously there's a space trade off there - it might not always be practical to do that
<lopex>
chrisseaton: all those are potentily to be 3-morphic on average case
ylluminate has joined #jruby
<chrisseaton>
lopex: how come?
<lopex>
all the methods
Aethenelle has quit [Ping timeout: 256 seconds]
<lopex>
chrisseaton: since ascii is ther first and utf the second most probable to be even loaded
<chrisseaton>
lopex: ok, but that doesn't mean any particular call site is going to see all three of them
<lopex>
so three lodaded classes
Aethenelle has joined #jruby
e_dub has joined #jruby
<lopex>
chrisseaton: in ruby code ?
<chrisseaton>
lopex: but just because you have three implementations of a method, doesn't mean any given call site to that method will have to deal with all three encodings - if you only ever use UTF-8, any call site on length with only ever refer to UTF-8's implementation
<lopex>
but the problems is most ruby string method callsites will see them ?
<chrisseaton>
lopex: I don't believe so - but I can't prove it without running an experiment on a corpus of Ruby code
<chrisseaton>
think about it like this - a particular part of Ruby code deals with incoming network strings - it might have to deal with lots of encodings, but if another part of your program, even using the same Ruby methods, only even sees UTF-8, then that's all it will have in its call site
<chrisseaton>
and if a string is allocated and used within a single method - like a temporary string - then the encoding is constant and we never need to check for it
<lopex>
er, and about jruby core code ?
<lopex>
not truffle ?
<chrisseaton>
lopex: same thing applies there - a call site only becomes polymorphic when it actually sees multiple classes - not just if it *could* see multiple classes
<lopex>
I understand that
<chrisseaton>
so an interface with 10 implementations doesn't matter if you only ever use 2
<lopex>
yeah
<lopex>
but the libraries use diferent encodings
<lopex>
and jruby core is uses by most
<lopex>
*used
claudiuinberlin1 has left #jruby [#jruby]
<lopex>
chrisseaton: I understand that by inlining/specialization it is mitigated
<chrisseaton>
and Truffle is really aggressive at both of those things for that reason
<lopex>
or am I missing someting fundamental
<chrisseaton>
we may be on different wavelengths - if you want to clarify what you mean you could show me some more code
<lopex>
chrisseaton: that I can appreciate/understand
<lopex>
chrisseaton: because it works differently
<lopex>
it's profile wise not call site wise
<lopex>
is that rght ?
<chrisseaton>
not sure what you mean by 'profile wise'
<lopex>
path-wise
<chrisseaton>
yeah you can think about it like that
<chrisseaton>
each call site might split, and call sites in the split method may be split again
<chrisseaton>
so you could say, in effect, you get a 'trace', like in PyPy
<lopex>
yeah I even read the paper :)
<lopex>
but it's a bit different there, since it's recursive
<chrisseaton>
our inlining is recursive, so it's similar
<nirvdrum>
Yay. Passing builds.
<nirvdrum>
headius: I suspect that's not very helpful for you though.
<lopex>
chrisseaton: but they claim it's because of the interpreter tracing the program
<lopex>
and then on itself
<chrisseaton>
yeah, so it's certainly different and the comparison is quite abstract
<lopex>
chrisseaton: anyways, sorry for stupid questions
<chrisseaton>
np - if you want to get involved we can tutor people to get them up to speed
<lopex>
chrisseaton: what I've learned on past work on jruby and joni/bigswitch gave me enough
<lopex>
chrisseaton: like they profiled the branches but made no use of it in the past
<lopex>
so like on normal compile tech a switch is a jump table or balanced tree
<lopex>
they did the same, but you had no idea why larged switches got 10x slower
claudiuinberlin has joined #jruby
<lopex>
chrisseaton: all that skewed by the jit
<chrisseaton>
PyPy wrote a regexp engine that was JIT compiled like Python - Truffle could do the same
<lopex>
I imagine
<lopex>
the possibilities are endless
<lopex>
btw fijal is a pole
Aethenelle_ has joined #jruby
<lopex>
chrisseaton: do you have an idea how to jit joni subexps ?
<lopex>
chrisseaton: there's complicated artificial stack for it
Aethenelle has quit [Ping timeout: 250 seconds]
Aethenelle_ is now known as Aethenelle
<lopex>
like, lots of frame skips
<chrisseaton>
lopex: I think a student was already looking at compiling regexps with Truffle - complicate artificial stacks are a Truffle specialiality, so that's fine
<lopex>
chrisseaton: I remeber you mentioning it
<lopex>
ok
<lopex>
cool
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<lopex>
chrisseaton: are aware of js truffle efforts ?
<lopex>
chrisseaton: or is nashorn going to benefit from aht ?
<chrisseaton>
nashorn's got their approaches to these problems - we use their parser but I'm not sure if we use anything else
<claudiuinberlin>
guys, sorry to bother, there is any kind of documentation about jruby internals? some of the wiki pages are 3 years old. :| The code base is quite big and I would love just to get a good overview :)
tenderlove has quit [Quit: Leaving...]
tenderlove has joined #jruby
<chrisseaton>
claudiuinberlin: what perspective are you coming from? if you tell us what your background is, what you're interested in, what you're trying to do, with can help you find where to get started
<claudiuinberlin>
well I have some ruby and java exp
<claudiuinberlin>
but my java skills are quite old :)
<claudiuinberlin>
so, let's say from a scale from 1 to 10 is like this: java 4, ruby 7
<chrisseaton>
can you think of something in Ruby you're interested in and want to know how JRuby does it?
lanceball is now known as lance|afk
purplefox has joined #jruby
<claudiuinberlin>
chrisseaton: honest answer: I have no clue. I just want to help jruby community. I use it every day, so I want to give back something.
<claudiuinberlin>
fixing bugs, writing docs, cleaning, anything. And if at the end of the day, I learn new stuff, even better.
x1337807x has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<chrisseaton>
claudiuinberlin: do you run Windows? We need someone to fix and test JRuby on Windows at the moment
mje113__ has quit [Quit: Connection closed for inactivity]
<claudiuinberlin>
chrisseaton: sorry, macosx :)
JRubyGithub has joined #jruby
JRubyGithub has left #jruby [#jruby]
<JRubyGithub>
[jruby] ratnikov opened pull request #2281: Make loading service extensions work with classloader path (jruby-1_7...fix-2055) http://git.io/-0UtgA
baroquebobcat has quit [Ping timeout: 244 seconds]
baroquebobcat_ is now known as baroquebobcat
x1337807x has joined #jruby
<chrisseaton>
what IR instruction do you get for a literal regexp? I can find the regexp *operand* - but I'm looking for the interpret method and that needs an instruction