You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org> on 2010/07/01 18:49:49 UTC
[jira] Created: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Eliminate page pooling using shared page instances that separate their structure from the mutable state
-------------------------------------------------------------------------------------------------------
Key: TAP5-1197
URL: https://issues.apache.org/jira/browse/TAP5-1197
Project: Tapestry 5
Issue Type: Improvement
Components: tapestry-core
Affects Versions: 5.2.0
Reporter: Howard M. Lewis Ship
This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889849#action_12889849 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #157 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/157/])
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1197:
------------------------------------------
Assignee: Howard M. Lewis Ship
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888663#action_12888663 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #154 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/154/])
TAP5-1197: Only track the page's dirty count in when the page pool is enabled (it is meaningless in the non-pooling mode)
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888428#action_12888428 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #153 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/153/])
TAP5-1197: Remove the Defense class and convert existing code to use Java's assert keyword
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888428#action_12888428 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #153 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/153/])
TAP5-1197: Remove the Defense class and convert existing code to use Java's assert keyword
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889243#action_12889243 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #155 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/155/])
TAP5-1197: Use an internally generated unique Long key to access PerThreadValues (which will be a more efficient Map key than a String), and make some other small optimizations
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-1197) Eliminate page pooling using shared page
instances that separate their structure from the mutable state
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-1197.
--------------------------------------
Fix Version/s: 5.2.0
Resolution: Fixed
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 5.2.0
>
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889243#action_12889243 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #155 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/155/])
TAP5-1197: Use an internally generated unique Long key to access PerThreadValues (which will be a more efficient Map key than a String), and make some other small optimizations
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889849#action_12889849 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #157 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/157/])
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12888663#action_12888663 ]
Hudson commented on TAP5-1197:
------------------------------
Integrated in tapestry-5.2-freestyle #154 (See [http://hudson.zones.apache.org/hudson/job/tapestry-5.2-freestyle/154/])
TAP5-1197: Only track the page's dirty count in when the page pool is enabled (it is meaningless in the non-pooling mode)
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (TAP5-1197) Eliminate page pooling using shared
page instances that separate their structure from the mutable state
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-1197:
------------------------------------------
Assignee: Howard M. Lewis Ship
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (TAP5-1197) Eliminate page pooling using shared page
instances that separate their structure from the mutable state
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-1197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-1197.
--------------------------------------
Fix Version/s: 5.2.0
Resolution: Fixed
> Eliminate page pooling using shared page instances that separate their structure from the mutable state
> -------------------------------------------------------------------------------------------------------
>
> Key: TAP5-1197
> URL: https://issues.apache.org/jira/browse/TAP5-1197
> Project: Tapestry 5
> Issue Type: Improvement
> Components: tapestry-core
> Affects Versions: 5.2.0
> Reporter: Howard M. Lewis Ship
> Assignee: Howard M. Lewis Ship
> Fix For: 5.2.0
>
>
> This has been suggested before, but the recent changes to class transformation API makes it much more reasonable to accomplish.
> The goal here is to identify all transient or mutable state in the page and store it via the PerThreadManager. This will be invisible to user code; the pages will appear to be individual instances with internal state ... but in fact, it will be a single instance (per locale) with all internal, mutable state stored elsewhere.
> Because this changes the semantics of some aspects of the component class transformation pipeline, there will be a compatibility mode that will allow pages to be pooled as with 5.1, while any third party libraries that contribute workers update.
> Why do all this? For large applications with very complex pages, this will be a big win, as Tapestry has been shown to strain the limits of available JVM heap (surprising to me, but apparently true) once you have a few dozen (or hundred) page instances (of each page type) floating around.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.