On May 8, 2012, at 9:00 AM, Henri Gomez wrote:
>>> Any date about back port/merge of OSX support in mlvm project ?
>>
>> What exactly do you think is missing? Does the build fail for you? John
>> updated the mlvm patches a couple of days ago to the recent hotspot-comp
>> repository versions
On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote:
>
> What's the behavior of @ForceInlining , in particular for
> MethodHandle.invokeExact() ?
We introduced that annotation as an experiment for inlining exact invokers for
LambdaForms (note: LambdaForm is not directly related
I managed to get MLVM to build on OS X Snow Leopard with Henri's scripts. Notes:
* I get a failure like this at the end of the build, but this appears
to be after the jdk/jre have successfully built (or at least it
appears to work fine): https://gist.github.com/749b4fe1d3b469644c11
* In order to g
On 05/09/2012 08:02 PM, Christian Thalinger wrote:
> On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote:
>
>> What's the behavior of @ForceInlining , in particular for
>> MethodHandle.invokeExact() ?
> We introduced that annotation as an experiment for inlining exact invokers
> for
On May 9, 2012, at 11:07 AM, Charles Oliver Nutter wrote:
> I managed to get MLVM to build on OS X Snow Leopard with Henri's scripts.
> Notes:
>
> * I get a failure like this at the end of the build, but this appears
> to be after the jdk/jre have successfully built (or at least it
> appears to
Lazy Method Handles is a project to defer code generation for method handle
behavior, and minimize requirements for support from hand-written assembly code.
The idea is to make all method handle behavior visible to the JVM compiler, so
that it can be optimized properly. Assembly code cannot be
Quite interesting John. A few curiosity based questions.
we are now representing the argument transformations using
a simple AST-like IR, called a LambdaForm
would this be something we could inspect, build or manipulate?
This form can be easily rendered down to bytecod
On May 9, 2012, at 11:15 AM, Rémi Forax wrote:
> On 05/09/2012 08:02 PM, Christian Thalinger wrote:
>> On May 8, 2012, at 2:11 AM, Garcia Gutierrez Miguel Alfredo wrote:
>>
>>> What's the behavior of @ForceInlining , in particular for
>>> MethodHandle.invokeExact() ?
>> We introduced that annot
On May 9, 2012, at 1:37 PM, Mark Roos wrote:
>
> Quite interesting John. A few curiosity based questions.
>
> we are now representing the argument transformations using
> a simple AST-like IR, called a LambdaForm
>
> would this be something we could inspect, build or manipu
from John
There may be a type-safe way to use them...
Well since I only have one type I guess I don't have to wait -)
regards
mark___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Thanks for the update, John! Comments below...
On Wed, May 9, 2012 at 2:34 PM, John Rose wrote:
> In JDK 7 FCS a method handle is represented as a chain of argument
> transformation blocks, ending in a pointer to a methodOop. The argument
> transformations are assembly coded and work in the in
I'm getting a lot of these messages trying to test against meth-lazy,
which is preventing me from validating it for larger benchmarks and
JRuby's test suite:
Invalid gemspec in
[/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/treetop-1.4.10.gemspec]:
=== DEBUG MESSAGE
Charlie,
Am 10.05.2012 um 06:36 schrieb Charles Oliver Nutter:
> Christian suggested -Xverify:all, which provides
> the following...so I guess something is generating bad code here?
>
> Invalid gemspec in
> [/Users/headius/projects/jruby/lib/ruby/gems/shared/specifications/trinidad_jars-1.0.3.gem
13 matches
Mail list logo
