headius

10 ms·

91.
by headius 14y ago
The author asserts that JRuby would consume more than 15GB of memory without providing any justification. Perhaps it would be better to actually try it rather than just making sweeping generalizations.
92.
by headius 14y ago
You certainly can do that. You can also add more and more locks to your doors while leaving your windows open.
93.
by headius 14y ago
You mean JRuby and Rubinius, but yes...it's as flawed as every other blacklisting security mechanism. We mostly don't implement it because, well, "here, add these security checks and tainting propagation to EVERY METHOD IN THE SYSTEM and
94.
by headius 14y ago
Because tainting is an inherently flawed way to do security. Blacklisting capabilities/methods/data always leaves holes behind, and it's nearly impossible to secure a system using tainting alone. Even the Perl folks say it shouldn't be us
95.
by headius 14y ago
I'll try to add some for you tonight :-)
96.
by headius 14y ago
I would say it is the second goal right now. Implementing JRuby and Mirah taught me a lot about features of Ruby that can map directly to Java/JVM, and I feel like this can be a very useful, functional subset of Ruby. Because this is a "com
97.
by headius 14y ago
MRI does GC runs like they're going out of style. I recently did some comparisons with JRuby and saw 100x more GC runs on MRI, and easily 10x more time doing those runs. GC::Profiler ends up eating a crapload of memory as a result. Check ou
98.
by headius 14y ago
Based on this comment, I started looking into JRuby support for the pg gem. I think it's possible; I have started stubbing it out, and the Postgresl JDBC driver publishes additional interfaces that provide everything folks here have been as
99.
by headius 14y ago
If you are smart, you'll run CI on JRuby. Then your test environment matches production.
100.
by headius 14y ago
Indeed we could, and as a reply mentions some implementations do take liberties with various Ruby features like $~ and $_ (in MacRuby they are thread-local, which sorta works but is often broken behavior). Part of my challenge as a Ruby imp
101.
by headius 14y ago
Yeah, I still don't agree with you. If I were compiling to JVM bytecode, would you no longer consider it a transcompiler? And if that bytecode were exactly what javac produced after compiling the Java source I emit now...what exactly is the
102.
by headius 14y ago
Did your experiment still do dynamic calls where Python would do dynamic calls? fastruby does not; all dynamic calls are converted into Java virtual dispatches, which optimize and inline like normal Java code. The 30% improvement I got on "
103.
by headius 14y ago
Efficient is a loaded term, so I'll skip that...but the JVM is most definitely a faster platform than CLR.
104.
by headius 14y ago
CoffeeScript is a transcompiler because it's largely just taking language A with semantics similar to JavaScript but different syntax and converting it directly to JavaScript. There's no static worldview as in fastruby, no exploitation of t
105.
by headius 14y ago
I disagree :) A transcompiler would have to be able to produce pretty much 1:1 mapping between one language and another. In this case, it would have to be emitting the equivalent of dynamic calls, which isn't really possible on the JVM (oth
106.
by headius 14y ago
JRuby does have an AOT compiler, but the resulting code must be shackled to the rather large JRuby runtime. Is also does a slower dynamic call that fastruby (except on invokedynamic). My goal with fastruby is more to have a still dynamicall
107.
by headius 15y ago
JRuby will be in GSoC, and may also have a separate "summer of code" via an as-yet-unnamed benefactor. Perhaps we should just get Yehuda to mentor a student to build a single "Rails.app" that runs on all platforms, rather than just OS X?
108.
by headius 15y ago
G1 is definitely an interesting piece of work. It's geared toward very large heaps where you need more predictable pause times, and is intended to replace the concurrent mark/sweep GC. To enable G1 on Java 7: -XX:+UseG1GC. Prepend -J if pas
109.
by headius 15y ago
I know some of the implementations there use native libraries that are built into python but only available via RubyGems for Ruby, like numpy. That makes it less of a language shootout (at times) and more of a "who ships the best C libs" sh
110.
by headius 15y ago
Memory is cheap? JRuby largely uses more memory because we have a "real" garbage collector. The JVM, unlike MRI, allocates much more memory than the app needs. That gives it freedom to delay GC runs and push old objects into rarely-GCed sec
111.
by headius 15y ago
We've been very lucky to have a lot of ingenious JRuby users help port some of those extensions or produce API-compatible wrappers around equivalent Java libs. There's still C exts we don't have equivalent JRuby exts for, but things are muc
112.
by headius 15y ago
That's definitely our hope. JRuby has come further than any implementation in making Ruby fast enough to replace C or Java, and if it's possible to write more in Ruby then all implementations will benefit. C extensions are the number one th
113.
by headius 15y ago
OpenSSL is a terribly complex library to support, but we've managed to steadily improve our pure-Java port (originally a herculean effort by Ola Bini, it wraps bouncycastle in an OpenSSL-lookalike API). There's still probably issues, but we
114.
by headius 15y ago
Yes, I'd say that's at least partially true. The innovation on JRuby's side is in new ways to integrate with the JVM, rather than in API or language design. MRI folks need to innovate both in how they design the language and APIs and in how
115.
by headius 15y ago
Cute :) In other news, I realized our "org.jruby:jruby-dist" maven artifact hasn't been publishing a full dist tarball, like it's supposed to, so we'll get that fixed.
116.
by headius 15y ago
EM does work, but it's not commonly used on JRuby. I think the fact that JRuby has real parallel-executing threads makes eventing frameworks like EM less interesting...especially since EM only runs a single event loop. I'd love to hear abou
117.
by headius 15y ago
That is truly bizarre. There's probably mirrors of the JRuby downloads somewhere, eh? I don't know them offhand...
118.
by headius 15y ago
Perhaps IcedTea (RedHat's fork of OpenJDK) has included a 64-bit plugin. I did not think OpenJDK/OracleJDK had done so yet...but I'd love to be proven wrong.
119.
by headius 15y ago
Rails runs quite well on JRuby, indeed. I have no information on its performance relative to other frameworks, though.
120.
by headius 15y ago
I find it a bit of a dodge when a dynamic language has to go to static types for performance. That's not to say I haven't wanted to have that dodge available to JRuby users, but being unable (or unwilling) to unilaterally add optional stati

More ›