I wouldn't touch this with a ten-foot-pole without an explicit patent grant. Oracle has misbehaved too much in the past (and present) to ever be trusted again by the open source community in my opinion.
You know it's really motivating to read such comments after you've released years of work as open source...
GraalVM: Run Programs Faster Anywhere
181–190 of 218 posts
Re: GraalVM: Run Programs Faster Anywhere
#182Earlier quoted context omitted.
OpenSSL and nokogiri already work pretty well. ActiveRecord works providing you have a database driver and I’ve got a rough set of patches for pg that I’m working on right now. I’m working on Discourse at the moment and can run the dB create and migrate tasks and I’m working on the asset compilation pipeline, but it’s all pretty rough and won’t be our final solution.
Just wondering if any Discourse or Rails Core people involved to get it working?
Re: GraalVM: Run Programs Faster Anywhere
#183Earlier quoted context omitted.
I'm not on the Graal team but I can take a crack at an answer - it's because as languages get more dynamic, static ahead of time compilation becomes less and less effective and can even be counterproductive. To compile a Ruby program it really needs to be just-in-time compiled, or at least a partial ahead of time compile using injected profiling runs. The problem is that the semantics of Ruby are such that you can't…
That's partly true, but depends on the particular program. There are Ruby programs that could be compiled ahead-of-time quite efficiently, despite their dynamic features. The slow-path version of the code that violates runtime assumptions can still be compiled as an alternative variant - so instead of switching from fast compiled code to the interpreter, the code violating the assumptions can switch to slow-path comp…
Dir.glob("some dir/*").each do |filename|
require filename
end
A lot of Ruby code messes with how code is loaded (heck, "require" in almost every Ruby install is not the built in "require" but one that has been dynamically replaced). Sometimes that is intended to implement static behavior: The expectation is that the code remains the same. It's just a way of avoiding having to maintain a list manually.But other times it is used as a plugin mechanism, where the expectation is for the code to be provided by a user or other developer, and processing this statically at compile time would remove capabilities that the user would expect.
You can't automatically determine things like that, because it is down to developer intent and the code does not document the intent.
So the problem goes deeper than being about being able to revert to a slow path: To compile Ruby in a meaningful way you need to make some level of trade-off in what aspects of Ruby you decide to treat as "ahead of time" vs runtime, because there is no clear rule that says "now the program has been loaded; everything after this is runtime".
Re: GraalVM: Run Programs Faster Anywhere
#184Going to try it out, but does anyone know offhand whether GraalVM can be ran within the Linux subsystem in Windows 10?
why would you want that... it should run directly on Windows too?!? Not sure what you gain from using the linux binary from LXSS. If you really insist, invoke instead as .exe so you can still use bash and other tools, but run the actual compile or runtime using the system-native implementation.
Re: GraalVM: Run Programs Faster Anywhere
#185Might this (today, tomorrow) become another way to get access to the wonderful Lucene from non-Java environments? A long, long time ago there was a GCJ-based solution, but it was never loved much (either the port or GCJ itself). SubstrateVM looks potentially delicious here edit: lol: talk about a low blow! > The community version does not support DWARF information. The enterprise version supports all native tools tha…
Re: GraalVM: Run Programs Faster Anywhere
#186Earlier quoted context omitted.
I think it’s a legitimate licensing concern. I’m surprised you called it FUD, given the high-profile case against Android (google). I was about to recommend we try it at my company and gave up as soon as I read “Oracle” in the company name. Call it FUD if you want but Oracle does have a damaged reputation.
It happens when companies don't behave as they should, and others lack the money to enforce how things should be. "James Gosling: Oracle vs Google" https://www.youtube.com/watch?v=JQ7xVO9lqD0
Re: GraalVM: Run Programs Faster Anywhere
#187> With the SubstrateVM it is possible to produce a single, statically linked native binary executable version of Graal.js, which doesn't need any JVM to run. How large is the resulting executable? There was some mention of shares libraries — is it possible to build a runtime that is callable from C? Relatedly, does the GraalVM java executable support JNI? I’m also curious about the runtime footprint in general; any i…
> How large is the resulting executable? A minimal executable is about 5 MB. > There was some mention of shares libraries — is it possible to build a runtime that is callable from C? Yes you can compile a JAR to a shared library with C function entry points. > Relatedly, does the GraalVM java executable support JNI? Yes. > I’m also curious about the runtime footprint in general; any idea what is the smallest possible…
> Real language VMs are quite a bit bigger - a hundred MB or so.
Don't know if you're trying to say Lua is not a real language, or just skipped the part about Lua.
Re: GraalVM: Run Programs Faster Anywhere
#188Earlier quoted context omitted.
It doesn't do that - we compile the Ruby interpreter to native, not the Ruby application. It's a little bit more complex than that in that we can run a Ruby application ahead of time up to a certain point where we compile it, and then when you run the application that state when it was compiled is restored. So we load the core library during compilation for example.
Genuinely interested in knowing this - if you can compile ruby , why cant you compile a program? Will this be the case for truffle python, js,etc ?
I would think that the fact that Ruby constructs that look like what would be compiler directives in a more static language (e.g., Ruby's “require” vs C’s “#include”) have their semantics defined in a way which both depends on and affects runtime state means that AOT compiling Ruby in the strict sense gets you very little, whereas running it to a certain point AOT and saving the runtime state gets you closer to what you'd expect from compiling based on usually-compiled languages.
Re: GraalVM: Run Programs Faster Anywhere
#189there is any roadmap to make available for MacOS?
GraalVM EE has a MacOS version that is free for evaluation uses. http://www.graalvm.org/downloads/ There are technical reasons we cannot have a CE for Mac OS as well. But we are working on that.
Re: GraalVM: Run Programs Faster Anywhere
#190Earlier quoted context omitted.
This was the first thought that crossed my mind. If I have a choice between running our stack 50 times slower (and thereby 50 times the cost) or running anything Oracle, I know which choice is cheaper and doesn't come with an existential threat to my company. Only governments and big corp are rich and reckless enough to take on this kind of risk willingly.
>> existential threat to my company There is like a bajillion people out there running Oracle Java, MySql, Virtualbox and so on. All of them Oracle products, and with permissive licenses. Where is this "existential treat" thing coming from?
All of those examples have dual commercial/copyleft licenses, none of them have permissive licenses. Moreover, the Free licenses are without explicit patent grants which may, therefore, be at risk of patent claims.