alex0ptr has quit [Remote host closed the connection]
alex0ptr has joined #jruby
Guest70 has joined #jruby
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 256 seconds]
haze has quit [Ping timeout: 258 seconds]
haze has joined #jruby
cschneid has quit [Ping timeout: 240 seconds]
cschneid has joined #jruby
Guest70 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest70 has joined #jruby
bbrowning is now known as bbrowning_away
pawnbox has joined #jruby
pawnbox has quit [Ping timeout: 240 seconds]
Guest70 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tcrawley is now known as tcrawley-away
drbobbeaty has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
prasun has quit [Quit: Leaving]
<chrisseaton>
lopex: if your application only runs for a short period of time, or doesn't allocate any memory in steady state (with or without escape analysis) it's useful
Guest70 has joined #jruby
<chrisseaton>
lopex: but to be honest I think this is more about a baseline for performance comparisons
<chrisseaton>
lopex: I understand some people hack their JVM to do this anyway
<lopex>
chrisseaton: yeah, even mri has such threshold
Guest70 has quit [Client Quit]
<lopex>
chrisseaton: but imagine a steady state, no allocation pressure, lots of escape analyzed things, then you could potentialy switch gc's
<lopex>
no to that one, but potentially better one wrt pauses etc
<lopex>
just thinking
<chrisseaton>
lopex: the JIT emits different code depending on your GC, and I think can even lay out objects differently, so it would be tricky
<lopex>
ah
enebo_ has quit [Quit: enebo_]
<lopex>
chrisseaton: I'm only aware of copying and mark/sweep, the G1 is a big mystery for me except that it operates in blocks and it can free whole blocks
<lopex>
so given the path I can imagine hotspot for example can instrument them differently
<lopex>
allocations / gc
<lopex>
chrisseaton: but can allocation intrinsics influence gc ones ?
<lopex>
well, thats another question
<chrisseaton>
it's not allocation so much as the barriers
<lopex>
so contention ?
<chrisseaton>
I think all JVM GCs are bump allocation
<chrisseaton>
That's another one of your sentence fragments
<lopex>
like bump the pointer ?
<lopex>
but that's allocation
<lopex>
then you have tlabs etc
<chrisseaton>
Bump the pointer means allocation is object = end_of_heap; end_of_heap += object_size
<lopex>
yeah
<chrisseaton>
It's thread local yes
<lopex>
and memset plus + identity hash + class set
<lopex>
that the alocation for me
<lopex>
and component set for arrays
<lopex>
chrisseaton: so tlabs are all mem copy collectors right ?
<lopex>
when promoted, it doesn really matter
<lopex>
am I correct ?
<lopex>
and also, does the old gen suffer any contention ?
<lopex>
it's read only then right ?
<lopex>
er
<chrisseaton>
tlabs are edens - they're copied out of yes
<lopex>
I mean unless you have copying collector, there's no contention issues
<chrisseaton>
The old gens are shared so yes there must be some kind of synchronisation there that could be contended.
<chrisseaton>
All serious collectors are copying or compacting.
<lopex>
marks and sweep too ?
<lopex>
young ones yes
<lopex>
but the old ones ?
<lopex>
I know G1 does that (at least thats the effect of using blocks)
<chrisseaton>
I really don't know much more about this area of VMs.
<lopex>
is it being actively researched now too ?
<chrisseaton>
Garbage collectors at all?
<lopex>
somewhat yes, like, apart from the algorithms - I mean the strategies when to switch, when to promote etc
<lopex>
or, I guess I mean the adaptiveness
<chrisseaton>
Yes lots of ongoing research - do you know about shenandoah?
<lopex>
I know there's a massive brainworks for that wrt gc generally
<lopex>
no
<lopex>
chrisseaton: but is there a pressure from any of Oracle competitors ?
<lopex>
like google and V8
<chrisseaton>
Shenandoah is from Red Hat - maybe headius knows all about it
<chrisseaton>
I don't know the collector that V8 uses
<chrisseaton>
Most practical collectors are a hybrid of named academic ideas
<lopex>
haha
<lopex>
actually, as always
<lopex>
chrisseaton: wrt mri, they were constantly tweaking RObject structures like making unions etc just to minimize the pressure
<lopex>
but this aproach has an end
<lopex>
and they will never make copying compacted collector
c0de1 has quit [Quit: Left...]
<lopex>
chrisseaton: one last thing before you'll get fed up with my bullshit talk, is there a notion like "a program is in steady state, and we proved no more allocations will acure then ..."
Guest70 has joined #jruby
Guest70 has quit [Client Quit]
<chrisseaton>
But what would you do with that info? Turn off the GC? As we said, it's baked into the JIT