bug in gaming with MLVM

[Daniel Latrémolière]

>> When trying MLVM, I have make the following test as in attachment
>> "Test.java".
>>
>> I have compiled and runned it three times (cf. "cmd.log") with bad
>> expected behaviour (only partial loop, not running up to 100000), and
>> one time with a crash (cf. "hs_err_pid1008.log").
>>
>> Are these problems already known bugs?
>>
>> Thank you very much,
>>
>> Daniel.
>>      
> Daniel, your test do a lot of String creation/parsing,
> I am almost certain that your test test more the GC that
> the method handle.
>
> try:
> java -verbose:gc ...
>    
I know. This code was mostly for learning JSR 292.

I was surprised in first version of test to see MethodHandle faster than 
direct invoke, then I modified code for adding this stupid counter (but 
sufficiently complex for probably not being inlinable by Hostpot) and I 
have the problem explained and solved.

Given micro-benchmarks are mostly impossible in JIT, my only small hope 
was comparing two situations optimized by JIT but where the JIT can not 
remove the loop.
In the first test (cf. under), I was using a simple allocation-copy as 
comparison (hoping Escape Analysis can not remove this and remove all 
code of my loop).

public static String increment(String value) {
         return new String(value);
}

Then I know the test was mostly a comparison using object allocation as 
reference, but it is a sufficiently realistic comparison for most Java 
mainstream programming (where some unuseful allocations are not removed 
by lazy programmers) and the most simple comparison, given all 
arithmetic code can be optimized by JIT if too simple. I don't currently 
plan to use JSR 292 in highly intensive computing loops, then comparing 
with an allocation was a sufficient test.

Daniel.