On Nov 9, 2015, at 3:27 AM, Aleksey Shipilev
wrote:
>
> I agree with Claes here: let's not touch the valueOf hotpath.
Probably the best way to fix the present problem is to use the valueOf hotpath
*more*, by having the zero-function call the appropriate valueOf function,
instead of cache a co
On Nov 9, 2015, at 3:37 PM, Claes Redestad wrote:
>
> so we should add some test cases that guards against Wrapper.zero references
> leaking through the public API and add stronger wording to Wrapper.zero
> documentation?
>
> I turned your test case below into a jtreg test, included added vari
On Nov 10, 2015, at 10:53 AM, Vladimir Ivanov
wrote:
>
> Regarding the fix, can we avoid touching primitive boxes and lazily cache the
> values on Wrapper side? "static final @Stable Object[] zeros" +
> Wrapper.zero() indexing that array by Wrapper.ordinal().
I would greatly prefer that. Usi
Thanks for the correction, John!
I completely overlooked MH type conversions and a note in
MethodHandle.constant about widening primitive conversion when primitive
constant if requested.
Claes, the test looks good! Probably it is worth an RFE for additional
test development in that area.
R
Hi,
so we should add some test cases that guards against Wrapper.zero
references leaking through the public API and add stronger wording to
Wrapper.zero documentation?
I turned your test case below into a jtreg test, included added variants
for the other integral primitive types:
http://cr
1. If the Wrapper.zero "leaks" as a reference into any of the public 292 API,
that would be a bug, since the API specifies that the conversion from a zero to
a box-reference is the same as mandated by the JLS for boxing conversion.
(This is like Integer.valueOf(x), not new Integer(x).)
2. Sinc
Looks much better now. Reviewed.
Best regards,
Vladimir Ivanov
On 11/9/15 4:36 PM, Claes Redestad wrote:
Vladimir,
thanks for asserting this. The j.l.invoke code is still rather foreign
to me, so I took extreme precautions to not change any semantics.
Simplified thusly:
http://cr.openjdk.jav
Vladimir,
thanks for asserting this. The j.l.invoke code is still rather foreign
to me, so I took extreme precautions to not change any semantics.
Simplified thusly:
http://cr.openjdk.java.net/~redestad/8141678/webrev.03/
Effects remain largely the same.
Thanks!
/Claes
On 2015-11-09 13:13
On 11/09/2015 02:13 PM, Claes Redestad wrote:
>> Can we avoid shared secrets by doing the following?
>>
>> @HotSpotIntrinsicCandidate
>> public static Byte valueOf(byte b) {
>> if (b == 0) return ZERO;
>> final int offset = 128;
>> return ByteCache.cache[(int)b + offset];
>> }
>
> I
> On 9 Nov 2015, at 14:36, Claes Redestad wrote:
>
> Vladimir,
>
> thanks for asserting this.
Indeed!
> The j.l.invoke code is still rather foreign to me, so I took extreme
> precautions to not change any semantics.
>
> Simplified thusly:
>
> http://cr.openjdk.java.net/~redestad/8141678/w
Claes,
I don't think Wrapper.zero identity matters (e.g. see
MethodHandles.constant [1] or InvokerBytecodeGenerator.emitConst).
So, you can considerably simplify your code by allocating fresh wrapper
instances.
Best regards,
Vladimir Ivanov
[1] public static
MethodHandle constant(Class
Hi Paul,
On 2015-11-09 09:42, Paul Sandoz wrote:
Hi Claes,
How much difference are you observing?
On jake startup this removes about 22Kb, 8 classes and some 1000+
objects from Hello World, and much of that will never be loaded with
this approach (Short.valueOf, Character.valueOf and Byte.v
Hi Claes,
How much difference are you observing?
If it is small perhaps it’s worth waiting to see if there are much larger
improvements we can make, as the non-obvious tight coupling also has it’s own
cost in terms of maintenance.
Can we avoid shared secrets by doing the following?
@HotSpotIn
On 2015-11-08 20:40, Peter Levart wrote:
On 11/08/2015 06:46 PM, Claes Redestad wrote:
It's worth considering, but j.l.reflect is already initialized by
this point in jake and I saw no real difference in heap dumps or
class loading order between this and an experiment where the ZERO
constan
On 11/08/2015 04:43 PM, Claes Redestad wrote:
> Hi,
>
> indy eagerly creates and initializes all integral type caches
> (Byte$ByteCache, Short$ShortCache) which has a small, measurable
> impact to jake startup and footprint. Exposing ZERO constants from Byte,
> Character, etc which are guaranteed
On 11/08/2015 06:46 PM, Claes Redestad wrote:
It's worth considering, but j.l.reflect is already initialized by this
point in jake and I saw no real difference in heap dumps or class
loading order between this and an experiment where the ZERO constants
were simply made public. Adding methods
It's worth considering, but j.l.reflect is already initialized by this point in
jake and I saw no real difference in heap dumps or class loading order between
this and an experiment where the ZERO constants were simply made public. Adding
methods to JavaLangAccess has its own overheads to consid
On 11/08/2015 06:08 PM, Peter Levart wrote:
On 11/08/2015 02:43 PM, Claes Redestad wrote:
Hi,
indy eagerly creates and initializes all integral type caches
(Byte$ByteCache, Short$ShortCache) which has a small, measurable
impact to jake startup and footprint. Exposing ZERO constants from
B
On 11/08/2015 02:43 PM, Claes Redestad wrote:
Hi,
indy eagerly creates and initializes all integral type caches
(Byte$ByteCache, Short$ShortCache) which has a small, measurable
impact to jake startup and footprint. Exposing ZERO constants from
Byte, Character, etc which are guaranteed to be
Hi,
indy eagerly creates and initializes all integral type caches
(Byte$ByteCache, Short$ShortCache) which has a small, measurable
impact to jake startup and footprint. Exposing ZERO constants from Byte,
Character, etc which are guaranteed to be identical to what's
returned from each respective
20 matches
Mail list logo
