On 05/01/2012 12:09 AM, Ulf Zibis wrote:
Hi Rémi,
Am 28.04.2012 00:42, schrieb Rémi Forax:
While you are there:
IntegerCache.cache/high/low are static final, so should be named
_upper case_.
Not done because the system property is also spelled in lower case.
Hm, but does that justify violat
Hi Rémi,
Am 28.04.2012 00:42, schrieb Rémi Forax:
While you are there:
IntegerCache.cache/high/low are static final, so should be named _upper case_.
Not done because the system property is also spelled in lower case.
Hm, but does that justify violating very common code conventions?
IMO it's
On 27/04/2012 23:38, Rémi Forax wrote:
:
I have moved the assert into the static block of IntegerCache.
For Alan, because IntegerCache is loaded when Integer.valueOf() is
called the first time
the assert code is checked around the same time so after the system
init but only once.
webrev is he
Hi Remi,
On 4/27/2012 3:38 PM, Rémi Forax wrote:
On 04/27/2012 05:29 AM, Joe Darcy wrote:
On 4/24/2012 8:01 AM, Alan Bateman wrote:
On 24/04/2012 14:56, Rémi Forax wrote:
Here, I don't really ask for tweaking something but more to remove
an assert
which do something which is unrelated to t
On 04/27/2012 02:14 PM, Ulf Zibis wrote:
Am 23.04.2012 19:35, schrieb Rémi Forax:
Hi guys,
I've found a case where assert is harmful because it doesn't
play well with Hotspot inlining heuristic.
[...]
I think it's a good idea to comment this assert.
Hi Ulf,
While you are there:
IntegerCach
On 04/27/2012 05:29 AM, Joe Darcy wrote:
On 4/24/2012 8:01 AM, Alan Bateman wrote:
On 24/04/2012 14:56, Rémi Forax wrote:
Here, I don't really ask for tweaking something but more to remove
an assert
which do something which is unrelated to the current algorithm.
In my opinion, it's a debug a
Am 23.04.2012 19:35, schrieb Rémi Forax:
Hi guys,
I've found a case where assert is harmful because it doesn't
play well with Hotspot inlining heuristic.
[...]
I think it's a good idea to comment this assert.
While you are there:
IntegerCache.cache/high/low are static final, so should be named
On 4/24/2012 8:01 AM, Alan Bateman wrote:
On 24/04/2012 14:56, Rémi Forax wrote:
Here, I don't really ask for tweaking something but more to remove an
assert
which do something which is unrelated to the current algorithm.
In my opinion, it's a debug assert used during the development
that sli
Am 24.04.2012 15:56, schrieb Rémi Forax:
Here, I don't really ask for tweaking something but more to remove an assert
which do something which is unrelated to the current algorithm.
In my opinion, it's a debug assert used during the development
that slip into the production code. The fact that th
On 24/04/2012 14:56, Rémi Forax wrote:
Here, I don't really ask for tweaking something but more to remove an
assert
which do something which is unrelated to the current algorithm.
In my opinion, it's a debug assert used during the development
that slip into the production code. The fact that t
On 04/24/2012 02:12 AM, Ulf Zibis wrote:
Hi Rémi,
I think, instead tweaking the java code, Hotspot inlining heuristic
should better be changed to count the bytes of the compiled code.
Than any code would benefit from, not only Integer.valueOf().
-Ulf
Here, I don't really ask for tweaking so
Hi Rémi,
I think, instead tweaking the java code, Hotspot inlining heuristic should better be changed to
count the bytes of the compiled code.
Than any code would benefit from, not only Integer.valueOf().
-Ulf
Am 23.04.2012 19:35, schrieb Rémi Forax:
Hi guys,
I've found a case where assert
On 04/24/2012 12:32 AM, Alex Lam S.L. wrote:
Just curious - I am assuming that assertions are disabled during the
test runs, so wouldn't one expect the "assert" statements to be
ignored / removed?
Obviously it didn't in this case, yet I thought we are expecting
constant conditionals to be optimi
Just curious - I am assuming that assertions are disabled during the
test runs, so wouldn't one expect the "assert" statements to be
ignored / removed?
Obviously it didn't in this case, yet I thought we are expecting
constant conditionals to be optimised, e.g. if (a == null) {...} to be
removed if
On 04/23/2012 07:43 PM, Mario Torre wrote:
2012/4/23 Rémi Forax:
The issue is that Hotspot also count the bytecodes related to assert
in its inlining heuristic.
If the assert is commented, the inlining tree is good.
[...]
Given that Integer.valueOf() is a method used very often and that if t
2012/4/23 Rémi Forax :
> The issue is that Hotspot also count the bytecodes related to assert
> in its inlining heuristic.
> If the assert is commented, the inlining tree is good.
[...]
> Given that Integer.valueOf() is a method used very often and that if the
> inlining fails,
> the escape anal
Hi guys,
I've found a case where assert is harmful because it doesn't
play well with Hotspot inlining heuristic.
I'm currently playing with a lambda modified implementation of java.util and
as you see below Integer.valueOf is considered as too big by Hotspot
to be inlined.
792
17 matches
Mail list logo
