Ok, hypothetical situation. What if a patch were crafted for OpenJDK
that could make it possible to safely fork(2) the JVM process. What
would it look like?
Obviously VM-critical threads would have to be restarted. Such a thing
is certainly possible; the Rubinius VM maintains background threads
fo
On Tue, Nov 29, 2011 at 05:12, Charles Oliver Nutter
wrote:
> And JRuby's not alone. Dalvik supports forking, which is a large part
> of why it's able to boot small Java applications so darn quickly; the
> base Dalvik process has already initialized a bunch of VM and Android
> state, and the foked
On Tue, Nov 29, 2011 at 2:17 AM, Fernando Cassia wrote:
> It exists, and it´s a work-around, but it works very well... nailgun. ;-)
>
> http://www.martiansoftware.com/nailgun/
Nailgun is a fairly limited solution that isn't really comparable to fork:
* There's no process isolation; one bad "nail
Just to make it clear here, I'm editing the subject...my interest is
in "process forking", not "open source forking" :)
- Charlie
On Tue, Nov 29, 2011 at 2:12 AM, Charles Oliver Nutter
wrote:
> Ok, hypothetical situation. What if a patch were crafted for OpenJDK
> that could make it possible to
Uh, sorry for the long wait...
That was another problem that occurs with invokedynamic, in particular
with ricochet frames.
I fixed it, pushed the changes and uploaded a new binary to
http://ssw.jku.at/General/Staff/LS/coro/.
- Lukas
On 2011-11-07 00:18, Charles Oliver Nutter wrote:
Ok, bug
Changeset: a798eba1f10a
Author:Lukas Stadler
Date: 2011-11-29 13:57 +0100
URL: http://hg.openjdk.java.net/mlvm/mlvm/hotspot/rev/a798eba1f10a
coro: fix for stack walking displaced ricochet frames
! coro.patch
___
mlvm-dev mailing list
ml
Hello friends!
Just updating you on the status of JRuby + invokedynamic, for those of
you following along.
About halfway through this month I did another pass at getting tests
passing with invokedynamic enabled, and finally turned on all uses (at
the time) of indy in JRuby! Hooray!
Last week, I
Interesting. I guess if you could save that state to disk and reload it
then you would have
the equivalent of the Smalltalk image concept. Although it seems like this
would be hard to
be op sys neutral.
It also seems it would help the warmup issue with Hotspot by preloadiing
its counters etc.
On Tue, Nov 29, 2011 at 18:32, Mark Roos wrote:
> I just finished a paper (link below) on JVM startup time which states that
> for small programs its around
> 70ms
I don´t know about your paper, but on my single-core Atom netbook with
1.6 Ghz CPU and 2 Gigs of RAM running WinXP SP3 and JRE 7.0, s
Am 29.11.2011 22:32, schrieb Mark Roos:
[...]
> I just finished a paper (link below) on JVM startup time which states
> that for small programs its around
> 70ms. So I assume there is some other startup time you are trying to
> improve? Or is the
> paper not applicable to the launching of a new pro
On 11/29/11 11:22 PM, Jochen Theodorou wrote:
> Am 29.11.2011 22:32, schrieb Mark Roos:
> [...]
>> I just finished a paper (link below) on JVM startup time which states
>> that for small programs its around
>> 70ms. So I assume there is some other startup time you are trying to
>> improve? Or is th
On Tue, Nov 29, 2011 at 4:34 PM, Thomas Wuerthinger
wrote:
> What kind of initialization work is this? Could the result of that work
> be cached?
I can describe the work done in JRuby's boot.
We have managed to get JRuby's basic runtime to start up pretty fast;
about 0.3 to 0.5s on my high-end M
Am 29.11.2011 23:34, schrieb Thomas Wuerthinger:
> On 11/29/11 11:22 PM, Jochen Theodorou wrote:
>> Am 29.11.2011 22:32, schrieb Mark Roos:
>> [...]
>>> I just finished a paper (link below) on JVM startup time which states
>>> that for small programs its around
>>> 70ms. So I assume there is some o
Awesome, thanks Lukas!
Hopefully when the next openjdk-osx-build runs, it will pick up these
changes, and we'll have a working coro impl on OS X too :)
- Charlie
On Tue, Nov 29, 2011 at 6:58 AM, Lukas Stadler wrote:
> Uh, sorry for the long wait...
> That was another problem that occurs with in
> Awesome, thanks Lukas!
>
> Hopefully when the next openjdk-osx-build runs, it will pick up these
> changes, and we'll have a working coro impl on OS X too :)
Oops, forgot to tweet about it yesterday.
http://openjdk-osx-build.googlecode.com/files/OpenJDK-1.8-x86_64-b11-201
Hi to all,
When building OpenJDK 8 yesterday, I could see in hg logs :
Changes
7112478: after 7105605 JRuby bench_define_method_methods.rb fails with NPE
Summary: Fixed several EA issues with Connection Graph construction.
Reviewed-by: never, twisti (detail / hgweb)
coro: fix for stack walking d
Ok, good news and not as good news!
The good news is that coro seems to be working in the latest
openjdk-osx-build, and it definitely improves JRuby's coroutine
performance!
For running bench_fiber_ring with 100 fibers passing 1000 messages,
here's numbers for the threaded impl:
100 fibers / 100
Seconds after I email...A DISCOVERY...
It seems like invokedynamic is causing headaches for coro. Here's the
numbers with coro fibers and JRuby's invokedynamic support turned
*off*:
100 fibers / 1000 passes: 0.076000 0.00 0.076000 ( 0.077000)
100 fibers / 1000 passes: 0.076000 0.00
18 matches
Mail list logo
