Home » Language IDEs » Objectteams » Multidispatch pattern with OT/J
| | |
Re: Multidispatch pattern with OT/J [message #522002 is a reply to message #515230] |
Fri, 19 March 2010 15:22 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
OK, I finally created this page: http://wiki.eclipse.org/OTPattern/Double_Dispatch
Feedback welcome.
Yesterday also Sven Efftinge published a reflection-based hack for multiple dispatch - and Carsten Pfeiffer already commented that OT/J would have this nicer solution.
In an email Carsten also alerted me of a potential performance issue: If roles are created for the sole purpose of performing the dispatch one might want to think of ways how the number of role instances can be reduced.
He mentioned the concept of lifting participants, asking whether that could possibly be used to force reusing a singleton role instance for all base instances of the same type. I have two comments for that:
- The lifting participant would have to re-implement the logic of smart lifting which would reduce the elegance of the solution
- If one role instance is re-used for several base instances it can no longer use callout bindings for forwarding to its base instance, because the base link will no longer be useful.
With these two restrictions a lifting participant would indeed be able to define a singleton policy for a role.
Normally, when I'd want to reduce the number of role instances I'd try to use static role methods, so no role would need to be created at all. However, double dispatch depends on having an instance for dispatching.
However, this would actually make for a quite simple and effective optimization behind the scenes: iff a role class does not define any fields any role creation due to lifting can be avoided, since only three pieces of information are needed: the reference to the base instance, the reference to the enclosing team and the role class that would be selected for lifting. I would think that this optimization would be easier to implement in the VM rather than by byte code transformation. However, I might just have to think harder of what the compiler could actually do here.
On a different note perhaps its not the instantiation that weighs heavy, but the caching, because all roles would remain in the team's cache as long as team and base are still alive. If cache size is an issue we could easily mark a role class as "transient", "one-way" or s.t. like that to tell the compiler that these roles never need to be stored in a cache. Again, if a role does not define state of its own, caching or not will hardly make a difference.
Let me know if either of these issues seem important to you.
cheers,
Stephan
[Updated on: Fri, 19 March 2010 15:28] Report message to a moderator
|
|
|
Re: Multidispatch pattern with OT/J [message #522258 is a reply to message #522002] |
Sun, 21 March 2010 21:27 |
Carsten Pfeiffer Messages: 34 Registered: July 2009 |
Member |
|
|
Stephan Herrmann wrote:
> OK, I finally created this page:
> http://wiki.eclipse.org/OTPattern/Double_Dispatch Feedback welcome.
Looks good to me!
>
> The lifting participant would have to re-implement the logic of smart
> lifting which would reduce the elegance of the solution.
This is indeed not nice. I didn't look deeply into the ILiftingParticipant
API, but I had thought that it would be possible to actually let the runtime
do the lifting for the very first object of a class and then put that into
some kind of HashMap<BaseClass,RoleInstance>. Then the participant could
simply look up the singleton role instance by the base class.
> However, this would actually make for a quite simple and effective
> optimization behind the scenes: iff a role class does not define any
> fields any role creation due to lifting can be avoided, since only three
> pieces of information are needed: the reference to the base instance, the
> reference to the enclosing team and the role class that would be selected
> for lifting. I would think that this optimization would be easier to
> implement in the VM rather than by byte code transformation. However, I
> might just have to think harder of what the compiler could actually do
> here.
I wouldn't actually go that far as making this an optimization behind the
scenes (although that might be a good idea as well). What I had in mind was
an explict decision by the user to use role singletons rather than having a
role instance for every base instance.
> On a different note perhaps its not the instantiation that weighs heavy,
> but the caching, because all roles would remain in the teams cache as long
> as team and base are still alive. If cache size is an issue we could
Yes, exactly that was my concern about using this pattern: many "useless"
role instances lingering in a big internal hashmap, when dealing with many
many instances of few (base) classes.
> easily mark a role class as "transient", "one-way" or s.t. like that to
> tell the compiler that these roles never need to be stored in a cache.
> Again, if a role does not define state of its own, caching or not will
> hardly make a difference.
That would solve the memory problem in an elegant way.
Cheers,
Carsten
|
|
| | |
Re: Multidispatch pattern with OT/J [message #573712 is a reply to message #568438] |
Fri, 19 March 2010 15:22 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
OK, I finally created this page: http://wiki.eclipse.org/OTPattern/Double_Dispatch
Feedback welcome.
Yesterday also http://blog.efftinge.de/2010/03/multiple-dispatch-and-poor-m ens-patter.html published a reflection-based hack for multiple dispatch - and Carsten Pfeiffer already commented that OT/J would have this nicer solution.
In an email Carsten also alerted me of a potential performance issue: If roles are created for the sole purpose of performing the dispatch one might want to think of ways how the number of role instances can be reduced.
He mentioned the concept of http://www.objectteams.org/distrib/new_in_1.4.html#liftingpa rticipant, asking whether that could possibly be used to force reusing a singleton role instance for all base instances of the same type. I have two comments for that:
The lifting participant would have to re-implement the logic of smart lifting which would reduce the elegance of the solution
If one role instance is re-used for several base instances it can no longer use callout bindings for forwarding to its base instance, because the base link will no longer be useful.
With these two restrictions a lifting participant would indeed be able to define a singleton policy for a role.
Normally, when I'd want to reduce the number of role instances I'd try to use static role methods, so no role would need to be created at all. However, double dispatch depends on having an instance for dispatching.
However, this would actually make for a quite simple and effective optimization behind the scenes: iff a role class does not define any fields any role creation due to lifting can be avoided, since only three pieces of information are needed: the reference to the base instance, the reference to the enclosing team and the role class that would be selected for lifting. I would think that this optimization would be easier to implement in the VM rather than by byte code transformation. However, I might just have to think harder of what the compiler could actually do here.
On a different note perhaps its not the instantiation that weighs heavy, but the caching, because all roles would remain in the teams cache as long as team and base are still alive. If cache size is an issue we could easily mark a role class as "transient", "one-way" or s.t. like that to tell the compiler that these roles never need to be stored in a cache. Again, if a role does not define state of its own, caching or not will hardly make a difference.
Let me know if either of these issues seem important to you.
cheers,
Stephan
|
|
|
Re: Multidispatch pattern with OT/J [message #573758 is a reply to message #573712] |
Sun, 21 March 2010 21:27 |
Carsten Pfeiffer Messages: 34 Registered: July 2009 |
Member |
|
|
Stephan Herrmann wrote:
> OK, I finally created this page:
> http://wiki.eclipse.org/OTPattern/Double_Dispatch Feedback welcome.
Looks good to me!
>
> The lifting participant would have to re-implement the logic of smart
> lifting which would reduce the elegance of the solution.
This is indeed not nice. I didn't look deeply into the ILiftingParticipant
API, but I had thought that it would be possible to actually let the runtime
do the lifting for the very first object of a class and then put that into
some kind of HashMap<BaseClass,RoleInstance>. Then the participant could
simply look up the singleton role instance by the base class.
> However, this would actually make for a quite simple and effective
> optimization behind the scenes: iff a role class does not define any
> fields any role creation due to lifting can be avoided, since only three
> pieces of information are needed: the reference to the base instance, the
> reference to the enclosing team and the role class that would be selected
> for lifting. I would think that this optimization would be easier to
> implement in the VM rather than by byte code transformation. However, I
> might just have to think harder of what the compiler could actually do
> here.
I wouldn't actually go that far as making this an optimization behind the
scenes (although that might be a good idea as well). What I had in mind was
an explict decision by the user to use role singletons rather than having a
role instance for every base instance.
> On a different note perhaps its not the instantiation that weighs heavy,
> but the caching, because all roles would remain in the teams cache as long
> as team and base are still alive. If cache size is an issue we could
Yes, exactly that was my concern about using this pattern: many "useless"
role instances lingering in a big internal hashmap, when dealing with many
many instances of few (base) classes.
> easily mark a role class as "transient", "one-way" or s.t. like that to
> tell the compiler that these roles never need to be stored in a cache.
> Again, if a role does not define state of its own, caching or not will
> hardly make a difference.
That would solve the memory problem in an elegant way.
Cheers,
Carsten
|
|
|
Goto Forum:
Current Time: Wed Apr 24 19:12:13 GMT 2024
Powered by FUDForum. Page generated in 0.04738 seconds
|