On 02/02/2012 04:45 AM, Mark Roos wrote:
> From Rémi
> Without the descriptors of invokedynamic and the code of the
> BSM, it's
>hard to tell.
>
> Yes but they have no invoke dynamics and I was just wondering if my
> indy part was causing the
> issue. Your answer told me that I s
On 02/02/2012 04:45 AM, Mark Roos wrote:
> from Rémi
>
> if you know it will never escape,you should use an int directly.
>
> Well I am trying to build a Smalltalk system which has no static types so
> I have to box the ints. Since the code I showed was programmer entered I
> need to stay w
Am 02.02.2012 12:21, schrieb Jochen Theodorou:
> Am 01.02.2012 12:38, schrieb Rémi Forax:
> [...]
>> This is weird,
>> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
>> for me,
>> with jdk7u2 and jdk8b23.
>
> I guess I will try jdk8b23 next and hope the bug vanishes over tim
On Feb 2, 2012, at 2:34 PM, Jochen Theodorou wrote:
> Am 02.02.2012 12:21, schrieb Jochen Theodorou:
>> Am 01.02.2012 12:38, schrieb Rémi Forax:
>> [...]
>>> This is weird,
>>> All tests but one in UberTestCaseJavaSourceGroovyPackagesSecurity pass
>>> for me,
>>> with jdk7u2 and jdk8b23.
>>
>> I
On Thu, Feb 2, 2012 at 4:47 AM, Rémi Forax wrote:
> It can be an escape analysis change.
> As far as I know, escape analysis don't work through indy call but
> if Charles see same performance as Java, escape analysis has to work ??
My comment was about using an iterator/cursor for iteration (no o
Some nice comments from Rémi
So if one call is not inlined in
the middle of the body of the loop, then the VM will
not remove your MutableInteger.
This could be what is causing the difference in time. I have seen some
mails that indicate indy
GWT depth ( methodHandle sta
Am 02.02.2012 14:37, schrieb Christian Thalinger:
>
> On Feb 2, 2012, at 2:34 PM, Jochen Theodorou wrote:
>
>> Am 02.02.2012 12:21, schrieb Jochen Theodorou:
>>> Am 01.02.2012 12:38, schrieb Rémi Forax:
>>> [...]
This is weird,
All tests but one in UberTestCaseJavaSourceGroovyPackagesSecu
Am 02.02.2012 19:40, schrieb Jochen Theodorou:
[...]
> Every help is very much appreciated.
On further investigation the error seems really to be related to one of
the parameters being an instance of a class with a private modifier set.
The key point in that is maybe that the class is not an inn
So I ran some tests using a simple benchmark using the jdk8-b23 from the
Openjdk google code.
Without tiered compile I get: ( times in nanoseconds )
52101000
53973000
20932000
with tiered on
493788000
521448000
513287000
34293
15048000
But if I invalidate all call sites before the benchmar
