Quantcast

[infinispan-dev] Data Container Changes Part 1

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[infinispan-dev] Data Container Changes Part 1

William Burns-3
Check out some of the new changes to the Data Container in Infinispan 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.

[1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

Radim Vansa
Regarding another use of Weighter in Caffeine: would it be possible to
guarantee that an object with weight 0 (or negative one) is never evicted?

R.

On 12/19/2016 10:10 PM, William Burns wrote:

> Check out some of the new changes to the Data Container in Infinispan
> 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.
>
> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

William Burns-3
Yes, definitely!

I made sure to check when I added Caffeine [1]  

I was thinking we could add that later if we really need the feature.

 - Will


On Tue, Dec 20, 2016 at 4:16 AM Radim Vansa <[hidden email]> wrote:
Regarding another use of Weighter in Caffeine: would it be possible to
guarantee that an object with weight 0 (or negative one) is never evicted?

R.

On 12/19/2016 10:10 PM, William Burns wrote:
> Check out some of the new changes to the Data Container in Infinispan
> 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.
>
> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

Radim Vansa
Perfect! This would reduce the only limitation of dist/replicated caches
in 2LC, while I am convinced that these have much better performance
(there have been some changes recently, so I have to re-run the perf tests).

So, how should that feature be exposed to users?

1) Annotating the value class with @NonEvictable or @Evictable(false)
- What if the user can't change the class definition? That would require
us to provide alternative way as well (listing classes in configuration)
- Should we set this fixed for a value class? Inheritance?
- Should we support also @NonEvictable keys?

2) Adding Flag.NON_EVICTABLE to the write
- Flags are a bit controversial, we shouldn't add more user-facing flags
- We need a Param for functional commands as well

3) Other ways?

Should we create another type of CacheEntry (-1), add a flag to
Metadata, or something else?

Radim


On 12/20/2016 03:33 PM, William Burns wrote:

> Yes, definitely!
>
> I made sure to check when I added Caffeine [1]
>
> I was thinking we could add that later if we really need the feature.
>
>  - Will
>
> [1]
> https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/Caffeine.java#L347
>
> On Tue, Dec 20, 2016 at 4:16 AM Radim Vansa <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Regarding another use of Weighter in Caffeine: would it be possible to
>     guarantee that an object with weight 0 (or negative one) is never
>     evicted?
>
>     R.
>
>     On 12/19/2016 10:10 PM, William Burns wrote:
>     > Check out some of the new changes to the Data Container in
>     Infinispan
>     > 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.
>     >
>     > [1]
>     http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>     >
>     >
>     > _______________________________________________
>     > infinispan-dev mailing list
>     > [hidden email]
>     <mailto:[hidden email]>
>     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>     --
>     Radim Vansa <[hidden email] <mailto:[hidden email]>>
>     JBoss Performance Team
>
>     _______________________________________________
>     infinispan-dev mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

Galder Zamarreño
The problem of annotations is that you need to modify the cached value, and the user might not be able to do that, e.g. not their code.

Flags are fine IMO. I only have two problems with them:

1. We don't separate user vs internal flags.
2. Flags can't carry values.

In functional, I've fixed this by doing Param (flag replacement in functional) only for user concerns, and they can carry values.

Cheers,
--
Galder Zamarreño
Infinispan, Red Hat

> On 20 Dec 2016, at 17:10, Radim Vansa <[hidden email]> wrote:
>
> Perfect! This would reduce the only limitation of dist/replicated caches
> in 2LC, while I am convinced that these have much better performance
> (there have been some changes recently, so I have to re-run the perf tests).
>
> So, how should that feature be exposed to users?
>
> 1) Annotating the value class with @NonEvictable or @Evictable(false)
> - What if the user can't change the class definition? That would require
> us to provide alternative way as well (listing classes in configuration)
> - Should we set this fixed for a value class? Inheritance?
> - Should we support also @NonEvictable keys?
>
> 2) Adding Flag.NON_EVICTABLE to the write
> - Flags are a bit controversial, we shouldn't add more user-facing flags
> - We need a Param for functional commands as well
>
> 3) Other ways?
>
> Should we create another type of CacheEntry (-1), add a flag to
> Metadata, or something else?
>
> Radim
>
>
> On 12/20/2016 03:33 PM, William Burns wrote:
>> Yes, definitely!
>>
>> I made sure to check when I added Caffeine [1]
>>
>> I was thinking we could add that later if we really need the feature.
>>
>> - Will
>>
>> [1]
>> https://github.com/ben-manes/caffeine/blob/master/caffeine/src/main/java/com/github/benmanes/caffeine/cache/Caffeine.java#L347
>>
>> On Tue, Dec 20, 2016 at 4:16 AM Radim Vansa <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>    Regarding another use of Weighter in Caffeine: would it be possible to
>>    guarantee that an object with weight 0 (or negative one) is never
>>    evicted?
>>
>>    R.
>>
>>    On 12/19/2016 10:10 PM, William Burns wrote:
>>> Check out some of the new changes to the Data Container in
>>    Infinispan
>>> 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.
>>>
>>> [1]
>>    http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>    <mailto:[hidden email]>
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>    --
>>    Radim Vansa <[hidden email] <mailto:[hidden email]>>
>>    JBoss Performance Team
>>
>>    _______________________________________________
>>    infinispan-dev mailing list
>>    [hidden email] <mailto:[hidden email]>
>>    https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

William Burns-3
In reply to this post by William Burns-3
I just wanted to let you all know that Part 2 of Data Container changes is now ready.  Go ahead and check it at out at our new feature that we are very excited about at [2] !

[2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html

On Mon, Dec 19, 2016 at 4:10 PM William Burns <[hidden email]> wrote:
Check out some of the new changes to the Data Container in Infinispan 9.0. Beta 1 [1].  Part 2 will be probably after Holiday break.

[1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

Dan Berindei
I have some small comments on the blog post. I didn't read almost any
of the code, so I guess I match the experience of a typical reader :)

1. Can you really use eviction="COUNT", like for the other memory types?
2. The address-count name is a bit odd, as it invites comparison with
the native pointers: are our addresses ints on 32-bit and longs on
64-bit, do we have something similar to compressed oops etc. I'd
rather call it initialCapacity, like the HashMap constructor argument,
to allow us more wiggle-room in the implementation. E.g. we don't need
the entry in the table to be just a "next" pointer, it could be a
proper entry with a pointer to the key and maybe even a hash code.
3. The details on the way we do the locking and the actual number of
ReadWriteLocks we use also sound like they could become out of date
quickly. I'd put these and the memory overhead in a "Implementation
Details" section.
4. Reading the code, it looks like address-count is also rounded up to
the next power of 2, I think that should be mentioned here (and in the
javadoc/schema).
5. Does bounded off-heap need extra locking?
6. 36 bytes for "an additional address pointer" seems a bit excessive
:) Here too, I'd rather give an estimate of the overhead instead of
trying to explain exactly what we're using those bytes for.

Cheers
Dan



On Tue, Jan 24, 2017 at 12:21 AM, William Burns <[hidden email]> wrote:

> I just wanted to let you all know that Part 2 of Data Container changes is
> now ready.  Go ahead and check it at out at our new feature that we are very
> excited about at [2] !
>
> [2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
>
> On Mon, Dec 19, 2016 at 4:10 PM William Burns <[hidden email]> wrote:
>>
>> Check out some of the new changes to the Data Container in Infinispan 9.0.
>> Beta 1 [1].  Part 2 will be probably after Holiday break.
>>
>> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

William Burns-3


On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <[hidden email]> wrote:
I have some small comments on the blog post. I didn't read almost any
of the code, so I guess I match the experience of a typical reader :)

1. Can you really use eviction="COUNT", like for the other memory types?

Yes, I was hoping people would assume that from me saying it isn't different.  But I can clearly state it.
 
2. The address-count name is a bit odd, as it invites comparison with
the native pointers: are our addresses ints on 32-bit and longs on
64-bit, do we have something similar to compressed oops etc. I'd
rather call it initialCapacity, like the HashMap constructor argument,
to allow us more wiggle-room in the implementation. E.g. we don't need
the entry in the table to be just a "next" pointer, it could be a
proper entry with a pointer to the key and maybe even a hash code.

It is a bunch of longs that each point to an entry object off heap.  I would love to have compressed oops, but we are kinda at the mercy of malloc so there is no way to guarantee where the addresses will be allocated at.
 
3. The details on the way we do the locking and the actual number of
ReadWriteLocks we use also sound like they could become out of date
quickly. I'd put these and the memory overhead in a "Implementation
Details" section.

Sure can.  The way this works is pretty intrinsic to the current design, since it utilizes these known facts to iterate over the entries with as minimal locking as possible.
 
4. Reading the code, it looks like address-count is also rounded up to
the next power of 2, I think that should be mentioned here (and in the
javadoc/schema).

I actually had it in here, but in my many edits it was lost.  I will add it back in.  It is actually in the javadocs already however it was missed in the schema, I will add it there.
 
5. Does bounded off-heap need extra locking?

It does I mention in the overhead it requires an additional lock.  I was trying not to go into super details.
 
6. 36 bytes for "an additional address pointer" seems a bit excessive
:) Here too, I'd rather give an estimate of the overhead instead of
trying to explain exactly what we're using those bytes for.

I can clarify it obviously isn't an additional address pointer.  I was trying not to be specific with the usage but rather give an approximation of the overhead instead.

As you may have noticed I was torn with how specific to be. Originally I had the document much more detailed about how things worked, but I tried to pair it down. I was thinking maybe if we thought there was interest I could go into more details in a future blog post.
 

Cheers
Dan



On Tue, Jan 24, 2017 at 12:21 AM, William Burns <[hidden email]> wrote:
> I just wanted to let you all know that Part 2 of Data Container changes is
> now ready.  Go ahead and check it at out at our new feature that we are very
> excited about at [2] !
>
> [2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
>
> On Mon, Dec 19, 2016 at 4:10 PM William Burns <[hidden email]> wrote:
>>
>> Check out some of the new changes to the Data Container in Infinispan 9.0.
>> Beta 1 [1].  Part 2 will be probably after Holiday break.
>>
>> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [infinispan-dev] Data Container Changes Part 1

William Burns-3
In reply to this post by Dan Berindei


On Tue, Jan 24, 2017 at 3:23 AM Dan Berindei <[hidden email]> wrote:
I have some small comments on the blog post. I didn't read almost any
of the code, so I guess I match the experience of a typical reader :)

1. Can you really use eviction="COUNT", like for the other memory types?
2. The address-count name is a bit odd, as it invites comparison with
the native pointers: are our addresses ints on 32-bit and longs on
64-bit, do we have something similar to compressed oops etc. I'd
rather call it initialCapacity, like the HashMap constructor argument,

The only issue I had with an argument name like initialCapacity is then I would assume the capacity (array) can grow, which it does not. Also the word just capacity makes me think I can't have more entries than that, which you can. Did you have any ideas on names or you really like initialCapacity?
 
to allow us more wiggle-room in the implementation. E.g. we don't need
the entry in the table to be just a "next" pointer, it could be a
proper entry with a pointer to the key and maybe even a hash code.

The problem with it being a proper entry is then the size is unknown, where as I know the size of all pointers. I can't really allocate a big block for the pointers then, and I wouldn't want to keep track of all of the pointers in Java since those would be on heap.
 
3. The details on the way we do the locking and the actual number of
ReadWriteLocks we use also sound like they could become out of date
quickly. I'd put these and the memory overhead in a "Implementation
Details" section.
4. Reading the code, it looks like address-count is also rounded up to
the next power of 2, I think that should be mentioned here (and in the
javadoc/schema).
5. Does bounded off-heap need extra locking?
6. 36 bytes for "an additional address pointer" seems a bit excessive
:) Here too, I'd rather give an estimate of the overhead instead of
trying to explain exactly what we're using those bytes for.

Cheers
Dan



On Tue, Jan 24, 2017 at 12:21 AM, William Burns <[hidden email]> wrote:
> I just wanted to let you all know that Part 2 of Data Container changes is
> now ready.  Go ahead and check it at out at our new feature that we are very
> excited about at [2] !
>
> [2] http://blog.infinispan.org/2017/01/data-container-changes-part-2.html
>
> On Mon, Dec 19, 2016 at 4:10 PM William Burns <[hidden email]> wrote:
>>
>> Check out some of the new changes to the Data Container in Infinispan 9.0.
>> Beta 1 [1].  Part 2 will be probably after Holiday break.
>>
>> [1] http://blog.infinispan.org/2016/12/data-container-changes-part-1.html
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Loading...