<headius>
I saw that but I thought I saw another one that looked like a real failure
<headius>
maybe it was just all fetching issues
<nirvdrum>
And the build is failing now because of the psych move, it looks.
triple_b has joined #jruby
<headius>
ok cool
<headius>
oh perhaps chrisseaton restarted the findbugs failures
<headius>
I don't even see them anymore
triple_b has quit [Ping timeout: 246 seconds]
enebo has joined #jruby
enebo has quit [Client Quit]
<headius>
I pinged mkristian on gitter
<eonwe>
Has any thought been given to the Java class proxy deadlocks (https://github.com/jruby/jruby/issues/1621)? Is the current loading mechnanism going to stay quite the same in the 9k?
deobalds has quit [Quit: Computer has gone to sleep.]
elia has joined #jruby
mister_solo has joined #jruby
<headius>
I never saw this issue :-\ That definitely should be fixed in both 1.7 and 9k
triple_b has joined #jruby
<eonwe>
I looked a bit into it and did not find a few lines -fix as at least one way to fix this would be to order the locks in some way and release them (and restart) if you're unable to lock more
<headius>
I'm looking into that as a short-term fix
<eonwe>
yeah, just one lock would solve this too but I am assuming that multiple locks are there for a purpose :)
<headius>
well, not really
lance|afk is now known as lanceball
<headius>
the locks were just naively there to protect the individual JavaClass instances
<headius>
a single lock will serialize proxy class creation, but we may be able to eliminate the lock altogether if we can get the proxy creation to be more atomic
havenwood has joined #jruby
<headius>
eonwe: are you "cky" or "jmiettinen" from the bug?
<eonwe>
Yeah, the latter one
<eonwe>
-Yeah. I was about to write Yeah, atomic creation would side-step the issue
kares_ has joined #jruby
kares has joined #jruby
tcrawley is now known as tcrawley-away
<headius>
I'm testing this fix now
<headius>
I believe the biggest fault this prevents is two threads getting different proxy classes for some Java class
<headius>
so another fix would be to only atomically update the proxy class and just let all threads have at it
<headius>
if they end up double-loading, only one will win anyway
<headius>
chrisseaton: a concern about your JavaSupport interface change
<headius>
I don't think we can do it as an interface because existing code that uses JavaSupport from Java would have to recompile
<headius>
invokevirtual != invokeinterface
tcrawley-away is now known as tcrawley
<headius>
would a pure-abstract superclass work ok?
<enebo>
The new world order is that closures will lazy like methods are now with regards to building from AST
<headius>
enebo: oh nice
<enebo>
all other scopes will immiedaitely build and make ic
<enebo>
so instrList will disappear and no longer be racing
<headius>
so uncalled closures never even get to IR?
<enebo>
right
<headius>
slick
<enebo>
that is how methods work right now too
<enebo>
methods are a bigger payoff
<enebo>
It is weird to think lazy prevents races too :)
<headius>
oh I'm sure, I remember your table of defined versus called methods
<headius>
so tldr for #1621 is that Java proxy creation has a lock per proxy, so it's easy to deadlock it with circular class references
<headius>
easy fix is a single lock but that obviously serializes all proxy creation
<headius>
which may or may not be a concern
<enebo>
So there is some forms of code where there are tons of blocks but in my opinion this won’t save much since most blocks in those scenarios always get called
<kares_>
chrisseaton maybe internal ones ... how would you expect native extension to work across 1.7 and 9K?
<kares_>
* extensions
<chrisseaton>
kares_: well I wouldn't - it's a major version number change - but I understand it's an inconvenience
<kares_>
chrisseaton :) it's more than that
<chrisseaton>
kares_: one problem is I'm not sure we have a public API and an internal one - it's all just classes in org.jruby isn't it?
<headius>
chrisseaton: small breakage, yes...changing all calls to JavaSupport from virtual to interface is not small
<headius>
we also need to consider exts that need to work across both impls, and this change makes that impossible
<headius>
both impls = both versions
halorgium has joined #jruby
<headius>
chrisseaton: we have never formally defined external API, unfortunately
<kares_>
chrisseaton I think there are ones that native extensions use - it's no where formalized but JavaSupport is one such thing
<headius>
API got big fast and it's unclear what subset ext authors need/use
<headius>
sorta like MRI :-)
<chrisseaton>
yeah
<headius>
we would like to use enebo's annotation to mark up the APIs we consider really and truly public, but that's obviously hard to prioritize versus bugs
<chrisseaton>
ok, well I'm happy with an abstract class anyway so no problem
<headius>
ok
<headius>
it's not ideal, but it is what it is
<kares_>
chrisseaton if you change an API looking at JRuby-OpenSSL / AR-JDBC is a good feedback whether it's "public" API
<headius>
other option would be adding a NEW interface and a NEW method to Ruby and leaving JavaSupport exactly the same
<enebo>
perhaps nirvdrum knows of a java static code analyzer to generate a report on a code base of which org.jruby methods are being consumed?
<enebo>
I have wanted something like this to run across all native exts to see what people are using and to at least make public blessed methods for things which should be internal
<enebo>
(and I don’t know why I singled out nirvdrum :) )
<nirvdrum>
Heh.
<chrisseaton>
new topic... I was thinking of creating a feature request in MRI for a Kernel#binding_of_caller method - it could be used to simplify the APIs of at least ERB and pry. Was going to run it by this room before submitting in case I'm embarrassing myself. Thoughts?
<enebo>
chrisseaton: So every single call we make will need to be able to spill locals just in case?
<nirvdrum>
headius, enebo: It might be good to adopt a versioned API approach. In 9k the classes could just be simple delegates of the old ones (or vice versa). But if you did that moving forward, you could support a moving window of n versions and extensions could target multiple versions of the API, rather than trying to target a single API across multiple versions.
<headius>
nirvdrum: indeed, that would be very nice
<chrisseaton>
enebo: you'd use it as an inlining hint - if A calls B that calls binding_of_caller, you should line A into B into b_of_c
<headius>
it would mean all methods that don't inline anything yet would have to fully deoptimize
<chrisseaton>
headius: in the interpreter you're using heap frames aren't you?
<headius>
yes, but we don't do our own inlining anywhere right now
<headius>
we just emit to JVM bytecode and invokedynamic inlines
<chrisseaton>
oh right so it would depend on new IR phases - I guess you're going to work on those at some point anyway though
<headius>
so we would *have to* be able to inline at IR level or every method in the system would have to deopt
<enebo>
we have the capability to inline but there is so much work before we can realistically inline
<nirvdrum>
enebo: I'm not sure about reporting, but ProGuard is able to tell what calls are being made. It's often used to extra bytecode to reduce overall binary size (popular on Android, I believe).
<chrisseaton>
I guess Rubinius can do it as they can natively read and write the stack of course
<chrisseaton>
ok I won't suggest this if it can't be done in JRuby yet
<headius>
chrisseaton: and they don't optimize anything
<enebo>
nirvdrum: hmmm I believe you mentioned this once before
<headius>
JRuby (and JRuby+Truffle) are the only implementations that even *can* eliminate frames
<enebo>
chrisseaton: It may be possible in the future to re-entertain this but I really would like it to be a language feature and not an API
<headius>
the concern is that adding this feature basically means every impl will have to support lazy frame reification or inlined frame deopt, or never be able to optimize frames away
<nirvdrum>
Rubinius supports it in some capacity, don't they?
<chrisseaton>
Every time I write ERB with .result(binding) I think this should be done for me
<enebo>
chrisseaton: Or at least if we can do and you do request it we say things like it cannot be aliased
<chrisseaton>
and binding.pry could become simply pry
<headius>
explicit is better than implicit
<headius>
I know we're not in python though :-)
<enebo>
I think there is a small class of tooling which would be greatly simplified by this but it requires a level of sphistication that we are not at yet to pull it off so it would punish all other cases to support it
<headius>
chrisseaton: for what it's worth, I think Binding.of_caller is a terrible idea anyway, since it breaks even further the encapsulation of local state
<headius>
I don't like anything that grants visibility into local variable state without explicit opt-in
<enebo>
headius: It does seem like this level of reflectivity goes against a programmers idea of safety
<enebo>
headius: but admittedly it seems like from a tooling perspective to be valuable. JVM at least forces the JVM into a mode for this sort of thing
<headius>
I hate Proc#binding for the same reason
<headius>
we need *less* magic/implicit access to local state, not more
graphex has quit [Read error: Connection reset by peer]
<enebo>
In my head I keep thinking this could also be used as an exploit to grab a method storing clear text password as a local
<headius>
(1..50).map {|i| Binding.of_caller(i).eval 'password' rescue nil} # dig through call stack looking for "password" local vars
<headius>
huzzah
<enebo>
in an open type system like Ruby it may be pretty easy if you get code injection just to put a “reader” method one level above in the inheritance change
<enebo>
but perhaps that is just paranoia
<enebo>
seems like a big potential vector though
<headius>
anyway, end of rant :-)
graphex has joined #jruby
<enebo>
hah
<enebo>
headius: I think a —debug sort of support for the idea would be fine though
<enebo>
headius: then tools like pry/irb could just enable it
<enebo>
Simplifying erb OTOH seems icky. Erb should probably be compiling their templates down to something not needing this
<chrisseaton>
We already have Truffle::Primitive.binding_of_caller and we use it internally - I guess I'll just leave it there
<headius>
chrisseaton: yeah, there's more than just optimization reasons I don't like the feature generally
<enebo>
chrisseaton: internally it is probably really useful for debugging
<chrisseaton>
enebo: we use it for #puts to set $_ in the caller
<headius>
fwiw, we could support --debug and Binding.of_caller by setting JIT to deopt everything too
<enebo>
chrisseaton: ah neat
<headius>
chrisseaton: ahh yes, and that's exactly why this is feature creep
<headius>
more and more stuff that requires implicit access to callers' bindings
<headius>
bad pattern going forward
<enebo>
$_ and $~ are the suck methods
<enebo>
err not really gvar lvars
<headius>
yeah
<headius>
fvars
<enebo>
svars for suck vars
<enebo>
but this was to copy Perl from way back when
<enebo>
and never intended to actually be globals
<enebo>
too bad Matz did not make a special sigil for this type of var
donV has quit [Quit: donV]
<chrisseaton>
If too many of these features get removed Truffle won't have a competitive advantage! (kidding)
<headius>
hahah
<headius>
I knew it!
<enebo>
From a legacy standpoint I understand how they came to be but as an implementor I don’t have to like them :P
<headius>
enebo: the worse/worst part of $_ and $~ is that they can be implicitly written *and* read
<headius>
so you have to be able to support their access even if they're never directly accessed
vtunka has quit [Quit: Leaving]
<enebo>
headius: yep
<enebo>
headius: although if you are pervasively inlining like Truffle they just do their trick and make a local one call frame up
<enebo>
err well wait not neccesarily inlining
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/xe3T
<JRubyGithub>
jruby/jruby-1_7 1ad3c67 Charles Oliver Nutter: Use a single global lock for proxy creation to avoid deadlocks....
JRubyGithub has left #jruby [#jruby]
<headius>
chrisseaton: I'd like to hear how the python impl is dealing with python's even-more-invasive frame access
<headius>
I assume it should work fine but there's probably some interesting cases
<enebo>
chrisseaton: So if you don’t inline you binding of call internally and add special lvar but then when you do inline you can reliminate it as a real variable and make it a temp or something like that?
<chrisseaton>
all our frames are real heap objects, it's just we escape analyse them most of the time, so you have as many heap objects in your compiled code as you do inlined methods, and you can read and write any of their fields
<enebo>
chrisseaton: When you mentioned binding_of_call impl specifically you just said inline the method calling it but that made me think you also use that strategy for things like puts?
<chrisseaton>
if a frame genuinely escapes (gets written to a global variable for example) we put it back on the heap
<enebo>
ok
<chrisseaton>
enebo: we inline puts by default, but it would still work if you didn't - it would just deoptimise the first time, and then the next time a method calls puts it would heap allocate in the first place - adaptively
<enebo>
I guess in my previous statements the other major difference is explicit lvars vs implicit created lvar from side-effect of calling a metho
<chrisseaton>
and our calls are the same for #send and normal calls, so it doesn't matter if you use metaprogramming
<chrisseaton>
enebo: if it doesn't exist lexically then the first time you set $_ will cause deopt, from then on we remember we needed it last time when we create new frames
vtunka has joined #jruby
<enebo>
chrisseaton: so essentially pretend it is lexical after that point
<chrisseaton>
yeah
<headius>
chrisseaton: it would be interesting to see what the cost of those heap frames looks like in a polymorphic case that can't inline
<enebo>
chrisseaton: yeah that is a nice trick
<chrisseaton>
headius: we should experiment, but I don't think it would be more expensive than the heap frames you already have in some cases - they're not catastrophic are they?
<headius>
our frames are pre-allocated and populated as needed
<enebo>
headius: they could also alloc that way though
<headius>
they could, and if JVM escape analysis was worth anything that would be the right thing to do
<enebo>
they would just end up with a lot less frames more likely
<enebo>
I like the idea we can rewrite callsite method if we encounter a scope which hits $_ or $~
<headius>
certainly
<enebo>
Worst case is a.puts is polymorphic we just have this extra var laying around
<chrisseaton>
you have like an object pool of frames?
<headius>
chrisseaton: yes
<headius>
they only allocate lazily if they are captured into a binding
<headius>
re-allocate lazily
<chrisseaton>
so there's not point relying on EA as you're only doing it if you think they're going to escape anyway
zorak8 has joined #jruby
<headius>
well, yes, but if we could rely on EA the current pooled version would make every frame escape
<headius>
we also have to pay the cost to clear each frame on the way out, which wouldn't happen it they just EA'd away
<enebo>
since we cannot easily replace the current method we are executing in I think this would be tough
<headius>
I should be clear about something too... frame here == method-level frame, not closure state
<headius>
closure local var store is still allocated for every entry
<headius>
$_ and $~ are method-level so they can live in the pooled frames
<chrisseaton>
you do have an inlining phase or some other special treatment for attr_accessors don't you?
<headius>
attr_accessors are native, but why would they need special treatment anyway?
mitchellhenke has joined #jruby
<enebo>
for inlining we plan on it but inlining is not really fully working atm
<enebo>
attr_* and Enumerable
<chrisseaton>
by special treatment I mean things like making it native
<headius>
the indy binding logic does bind attr accesses directly through
bbrowning_away is now known as bbrowning
<headius>
it would even if they were implemented in ruby
<enebo>
headius: but we still want to inline them as Ruby impls eventually to get rid of prologue/return instrs
<enebo>
headius: perhaps hotspot does it already
subbu has joined #jruby
<enebo>
headius: but we should be able to inline to @foo in the calling method
<headius>
sure
<enebo>
I guess we still need a cheap guard for it to be effective though
<headius>
they should inline with indy now though
<headius>
and they don't have side effects
<enebo>
at hotspot level though
<enebo>
as opposed to in IR where we can potentially do passes on that and make other higher level opts
<enebo>
That is really hand wavy
<headius>
on 1.7, pure-ruby attr reader is 50% slower than native attr_reader
<enebo>
but conceivably if we had 4 read references to @foo we could only do one get_field and everything else would end up just being a stack read
<headius>
that 50% could probably be eliminated
<enebo>
once we inlined stuffs
<headius>
kares_: looking at 2014 now
<enebo>
but I am not super bullish and I am not sure how far we can take that
<enebo>
since profiling from our last attempt was a pretty noticeable overhead
<headius>
enebo: concurrency's a concern there, obviously
<enebo>
yeah definitely. perhaps too much a concern to do
<enebo>
but if it is literally four reads in a method body there is a lack of determinancy
<enebo>
so we can pretend they cannot be different so long as no calls are between them which could create some sort of synchronization
<enebo>
anyways it was mostly just trying to point out that inlining ar IR level may provide a different level of optimizations than having hotspot do it
<headius>
for sure
colinsurprenant has joined #jruby
<headius>
kares_: I'm not sure I understand *why* there's a race here
<kares_>
headius the issue is eraly on it sometimes matched Enum.valueOf instead of the valueOf method from the enum sub-class
<headius>
right, but what causes that to race?
<kares_>
multiple threads?
<headius>
but I mean what data is one thread seeing the other doesn't
<headius>
well proxy class should be locked for duration of creation and remain the same after that
<headius>
but there are some structures built up to support overloaded methods, maybe that's not safe
<kares_>
headius heh not sure - maybe I was looking at the wrong place
<headius>
yeah we need to go deeper
<headius>
script in that bug fails for me almost every time
<kares_>
same here - with a few changes I've made that "improved" the code - it's now harder at my end - but still happens 1 in 3-5 runs
<headius>
ok
<headius>
enebo: I think I need to work on JavaClass/proxy init stuff
<headius>
try to fix both #1621 and #2014 correctly
<enebo>
headius: great
<enebo>
I am wandering in the desert but this will be worth it
<enebo>
headius: The second part of this will be a JITContext to match InterpreterContext
<headius>
perfect
<enebo>
headius: That will same some memory as a bonus
<enebo>
same=save
<headius>
yeah, I'll toss it out when I'm done jitting
<enebo>
headius: well or not…that is yet to be determined although we can for now
iamjarvo has joined #jruby
<enebo>
headius: The decision there is whether to record what passes happened in JITContext and fall back to very primitive but sa/feconservative IC or to allow JIT context to fall back to its own safe spot
<enebo>
The concept of deopt is not really realized now as it was originally envisioned
<enebo>
but that is blue sky compared to .0
<headius>
oh sure
<enebo>
other than hard fail-over
<enebo>
like too many bytecodes
<headius>
if we wanted to incrementally optimize it would be worth keeping around
<enebo>
headius: yeah
<chrisseaton>
You guys should write up the IR for DSL (Dynamic Language Symposium) deadline in June
<enebo>
chrisseaton: Wandering in the desert: Changing Java static optimizing compiler to a Ruby runtime
<chrisseaton>
they're always interested in more than just JS and Python, which is usually what they get
<enebo>
Hat’s off to subbu most of what he originally wrote is useful and just needed tweaking but we have run into so many things due to the mismatch between the two languages
<enebo>
I think our biggest problem is that this really is a compiler arch and is not well-suited to interpretation
<enebo>
which is I think ok since we plan on speed through JIT’ing largely (Android people plug your ears)
<chrisseaton>
you could always emit from IR your own fairly low level bytecode and interpret that
<enebo>
chrisseaton: believe me we have spent many hours talking about that
<chrisseaton>
or maybe write a Java bytecode interpreter in C and use JNI...
<enebo>
chrisseaton: My main believe is if we can emit back to a simple tree ala AST we can get good perf but that hurts startup
donV has joined #jruby
<donV>
Hi all!
<chrisseaton>
With trees you have chronic call overhead though
<enebo>
chrisseaton: simulating ipc machine with load/stores is a pretty big penalty for us
<enebo>
chrisseaton: yeah
<enebo>
chrisseaton: Sort of picking our poison a bit
e_dub has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] mkristian pushed 1 new commit to master: http://git.io/xerw
<JRubyGithub>
jruby/master fffd2b6 Christian Meier: let travis be green - maybe a regression due to the new psych default gem or something else
JRubyGithub has left #jruby [#jruby]
<headius>
donV: hello!
<donV>
headius: Hi! How are you doing?
skade has quit [Quit: Computer has gone to sleep.]
dinfuehr has joined #jruby
<enebo>
chrisseaton: re you call overhead you are correct but we noticed that callsites more often than not ended up being monomorphic so AST performed ok with hot code since those little callNodes would inline into each other
<enebo>
AST interp methods were not very big
<kares_>
headius ... so there's 2 StaticMethodInvoker-s created which seems wrong, one used only early on ends up with java.lang.Enum while the other does the correct thing
<kares_>
the do get the same proxy-class (host) ... but end up matching different methods in findCallableArityOne
<headius>
donV: working on simplifying JI proxy binding
<headius>
kares_: ok very interesting
<subbu>
enebo, chrisseaton headius ya .. i guess i originally thought even the ipc with loads/stores would be cheaper than ast call overheads .. but looks like i was wrong on that one.
<headius>
I'm working my way up from JavaClass to simplify the creation process
<enebo>
subbu: Also the passes you ended up making ended up being more and more conservative so that chipped away as well
<chrisseaton>
donV you may wonder why it doesn't see the new version automatically - the answer is that in buildbot, which we use for our CI, you need to define your tasks before you've see the repo contents
<donV>
chrisseaton: yeah, would be nice to automate it, but versions don’t change THAT often…
<kares_>
headius: think it would work if the super (proxy) classes were also locked while constructing the proxy class ... otherwise it's all about a method being picked up by the call site (from super while sub-class is not fully ready) https://gist.github.com/kares/c16b6a584a80689d7f08
skade has joined #jruby
<kares_>
is that the right way to go ... if so I can probably nail it down (with some aditional cleanup) ?
ypasmk_ has joined #jruby
ypasmk has quit [Ping timeout: 245 seconds]
lanceball is now known as lance|afk
<kares_>
... also for testing it's simpler to use an enum that does not have internal classes such as javax.lang.model.SourceVersion
anaeem1_ has quit [Remote host closed the connection]
<headius>
realized that there's logic right now to return empty, unpopulated proxy class in some cases like recursively binding the same class
<headius>
that could result in a call site seeing an uninitialized proxy, perhaps
anaeem1 has joined #jruby
Hobogrammer has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to jruby-1_7: http://git.io/xvql
<JRubyGithub>
jruby/jruby-1_7 e53e2cb Charles Oliver Nutter: Clean up imports.
JRubyGithub has left #jruby [#jruby]
<bjfish2>
How can I run a single spec? For example spec/ruby/core/symbol/shared/length.rb ?
<headius>
bjfish2: jruby spec/mspec/bin/mspec run ...
anaeem1 has quit [Ping timeout: 272 seconds]
lance|afk is now known as lanceball
<kares_>
headius: actually had some cleanup of those that improved installer's performance
<headius>
oh yeah? that's great
<headius>
proxy binding is one of the slower parts of boot right now
<kares_>
I guess you do not want to take my mega cleanup in :)
skade has quit [Ping timeout: 265 seconds]
<kares_>
... but I have test in case you do !
<headius>
perhaps I should have taken it in before refactoring, but we could/should try to use it
<kares_>
yep - noticed it's slow ... that is why I started the cleanup as well before reaching into the main bug (fixed some along the line)
<headius>
test case would be great
<headius>
where's the improved version?
<kares_>
headius: should I just should in a PR for review?
<headius>
yeah do that
<headius>
I will make the changes you've made in my refactor
<headius>
and then we can go form there
<headius>
kares_: I've always wanted to get rid of the two-step binding process (installer as intermediate step) but have not ifgured out a good way
havenn has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] kares opened pull request #2624: java support cleanup and improvements (jruby-1_7...test-java-support-improvements11) http://git.io/xvGg
DrShoggoth has quit [Remote host closed the connection]
elia has quit [Quit: Computer has gone to sleep.]
havenn is now known as havenwood
enebo has quit [Quit: enebo]
camlow32_ has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to test-refactor-ji: http://git.io/xv7k
<JRubyGithub>
jruby/test-refactor-ji 725df3f Charles Oliver Nutter: Move more binding logic into initializers.
JRubyGithub has left #jruby [#jruby]
colinsurprenant has quit [Quit: colinsurprenant]
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius closed pull request #2624: java support cleanup and improvements (jruby-1_7...test-java-support-improvements11) http://git.io/xvGg
JRubyGithub has left #jruby [#jruby]
camlow325 has quit [Ping timeout: 252 seconds]
pietr0 has joined #jruby
cultureulterior1 has joined #jruby
cultureulterior1 has quit [Client Quit]
pietr0 has quit [Ping timeout: 265 seconds]
iamjarvo has joined #jruby
pietr0 has joined #jruby
camlow32_ has quit [Remote host closed the connection]
DrShoggoth has joined #jruby
iamjarvo has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
mkristian has joined #jruby
enebo has joined #jruby
<headius>
kares_: just about caught up again
<kares_>
headius: heh - I almost thought twice I found it
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish opened pull request #2625: Adding Examples of Running a Single Spec (master...patch-1) http://git.io/xfI2
JRubyGithub has left #jruby [#jruby]
<headius>
all Initializer state and logic now lives outside JavaClass
<headius>
including the post-initialize "setup" stuff
<kares_>
seen that ... looks certainly more readable
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] headius pushed 1 new commit to test-refactor-ji: http://git.io/xftO
<JRubyGithub>
jruby/test-refactor-ji be31344 Charles Oliver Nutter: Pull all initialize logic up and out into initializer classes.
JRubyGithub has left #jruby [#jruby]
<headius>
kares_: there
bbrowning_away is now known as bbrowning
<kares_>
ah there's more :)
<headius>
yes...we shouldn't have to look at JavaClass at all to work on binding logic
<headius>
this was part of a grand vision to eliminate JavaClass and just add its functionality to java.lang.Class
<kares_>
I recall you guys having that discussion in Potsdam ... also the refactoring of JavaField
_djbkd has joined #jruby
Aethenelle has joined #jruby
<kares_>
headius: ah you were right --- just realized (while looking at your changes) to try out valueOf - that seems to work (no longer able to hit #2014) ... it's an alias uber-f*ck
<headius>
ahhh interesting
colinsurprenant has joined #jruby
<headius>
I wonder if the unfinishedProxy stuff is still needed
<headius>
originally that was added (by someone not me) to allow the second phase of binding (setup*) to happen lazily
<headius>
lazily didn't help all that much later on and I made it eager
<headius>
and there were other reasons
<kares_>
headius think it is ... failing for now if it's not set
camlow325 has joined #jruby
<kares_>
but have not looked deeper why
<headius>
I'm thinking we could just use proxyModule and proxyClass though
<headius>
maybe
camlow325 has quit [Read error: Connection reset by peer]
<kares_>
that's some crazy code ... esp. under concurrency - you'll see :)
<headius>
yeah I know
<kares_>
my head did not wrap around it ... not that I tried that hard
camlow325 has joined #jruby
<headius>
do you have some other cases to exercise this under concurrency?
<kares_>
2 tests are there - I think they exercise package resolution under concurrency
<kares_>
otherwise not
PragTob has quit [Remote host closed the connection]
camlow32_ has joined #jruby
<kares_>
also it's not the value_of alias thing ... it's just much rarer to hit at mines ;(
camlow325 has quit [Read error: Connection reset by peer]
codefinger has joined #jruby
<headius>
kares_: I think with latest round of changes I can make a single atomic reference for proxy class and eliminate the lock
<headius>
concurrent threads trying to boot a proxy might double up work but worst case that work gets thrown away
camlow32_ has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
donV has quit [Ping timeout: 246 seconds]
tenderlove has quit [Quit: Leaving...]
camlow325 has quit [Remote host closed the connection]
tenderlove has joined #jruby
bjfish2 has quit [Ping timeout: 246 seconds]
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
<kares_>
found a goto: label ... in the installer code - that code must be old :)
camlow325 has quit [Remote host closed the connection]
camlow325 has joined #jruby
<headius>
hah nice
camlow325 has quit []
camlow325 has joined #jruby
<headius>
I'm trying to get JavaClass completely out of this process
camlow325 has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
camlow32_ has quit [Remote host closed the connection]
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
camlow32_ has joined #jruby
colinsurprenant has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow325 has quit [Ping timeout: 245 seconds]
mkristian has quit [Ping timeout: 245 seconds]
camlow325 has joined #jruby
camlow325 has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
camlow325 has quit [Remote host closed the connection]
camlow32_ has joined #jruby
codefinger has quit [Read error: Connection reset by peer]
camlow32_ has quit [Read error: Connection reset by peer]
yfeldblum has joined #jruby
camlow325 has joined #jruby
deobalds has quit [Quit: Computer has gone to sleep.]
camlow325 has quit [Read error: Connection reset by peer]
camlow32_ has joined #jruby
camlow32_ has quit [Read error: Connection reset by peer]
camlow325 has joined #jruby
multibot_ has quit [Remote host closed the connection]
multibot_ has joined #jruby
calavera has joined #jruby
_JKL_ has joined #jruby
DomKM has quit [Quit: Connection closed for inactivity]
<Aethenelle>
headius: most of the VMs currently supported are easily created with qemu and debootstrap. I should have a blog post together soonish.
finch has joined #jruby
<Aethenelle>
If I get extra crazy, I may reimplement debootstrap in Ruby so it can be used on osx as well maybe even go so far as to make something vaguely vagrant-y
<headius>
sounds great :-)
robbyoconnor has joined #jruby
bjfish2 has joined #jruby
robbyoconnor has quit [Quit: Konversation terminated!]
calavera has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
calavera has joined #jruby
colinsurprenant has quit [Quit: colinsurprenant]
<headius>
trolls?
enebo has quit [Quit: enebo]
triple_b has joined #jruby
JRubyGithub has joined #jruby
<JRubyGithub>
[jruby] bjfish opened pull request #2626: [Truffle] Passing through encoding information from SymbolNode (master...truffle_symbols_encoding) http://git.io/xUEq
JRubyGithub has left #jruby [#jruby]
triple_b has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]