[jira] [Commented] (TAP5-2546) Parallel class loading
[
https://issues.apache.org/jira/browse/TAP5-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950411#comment-15950411
]
Hudson commented on TAP5-2546:
--
FAILURE: Integrated in Jenkins build tapestry-trunk-freestyle #1615 (See
[https://builds.apache.org/job/tapestry-trunk-freestyle/1615/])
TAP5-2546: use class loading lock for synchronization This does not
(jochen.kemnade: rev 77a2cc3769450d4a90004b1d72ce75c156c6a711)
* (edit)
plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassLoader.java
TAP5-2546: register PlasticClassLoader as parallel capable (jochen.kemnade: rev
627df8511604bc969af4e59ed34fb9578ed1586d)
* (edit)
plastic/src/main/java/org/apache/tapestry5/internal/plastic/PlasticClassLoader.java
> Parallel class loading
> --
>
> Key: TAP5-2546
> URL: https://issues.apache.org/jira/browse/TAP5-2546
> Project: Tapestry 5
> Issue Type: Sub-task
> Components: plastic
>Reporter: Michael Mikhulya
>Assignee: Jochen Kemnade
> Fix For: 5.5.0
>
>
> I would like to improve page loading time by improving its concurrent
> execution.
> Here is a first patch related to it: TAP5-2545
> Now the worst place from lock contention point of view is synchronization on
> {{PlasticClassLoader}}. Actually there are two kind of synchronization:
> {{synchronized}} methods in {{PlasticClassLoader}} and {{synchronized
> (loader)}} sections in {{PlasticClassPool}}.
> Recently most class loaders added support for parallel class loading:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=464442
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57681
> If we would like to split global lock, then we can use following trick for it.
> We can substitute code like this:
> {code:title=PlasticClassLoader.java}
> public synchronized Class defineClassWithBytecode(String className,
> byte[] bytecode)
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> {code}
> with following one:
> {code:java}
> public Class defineClassWithBytecode(String className, byte[] bytecode)
> {
> synchronized (className.intern())
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> }
> {code}
> It is just an idea to quickly check solution.
> Can anybody check and discuss idea? Or even better to fix issue. :-)
> I'm not an expert in concurrency and afraid making changes in such a critical
> place at least before somebody reviewed my idea. So any feedback would be
> appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TAP5-2546) Parallel class loading
[
https://issues.apache.org/jira/browse/TAP5-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950406#comment-15950406
]
ASF subversion and git services commented on TAP5-2546:
---
Commit 77a2cc3769450d4a90004b1d72ce75c156c6a711 in tapestry-5's branch
refs/heads/master from [~jkemnade]
[ https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;h=77a2cc3 ]
TAP5-2546: use class loading lock for synchronization
This does not change the previous behavior since PlasticClassLoader is not
(yet) registered as parallel capable
> Parallel class loading
> --
>
> Key: TAP5-2546
> URL: https://issues.apache.org/jira/browse/TAP5-2546
> Project: Tapestry 5
> Issue Type: Sub-task
> Components: plastic
>Reporter: Michael Mikhulya
>
> I would like to improve page loading time by improving its concurrent
> execution.
> Here is a first patch related to it: TAP5-2545
> Now the worst place from lock contention point of view is synchronization on
> {{PlasticClassLoader}}. Actually there are two kind of synchronization:
> {{synchronized}} methods in {{PlasticClassLoader}} and {{synchronized
> (loader)}} sections in {{PlasticClassPool}}.
> Recently most class loaders added support for parallel class loading:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=464442
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57681
> If we would like to split global lock, then we can use following trick for it.
> We can substitute code like this:
> {code:title=PlasticClassLoader.java}
> public synchronized Class defineClassWithBytecode(String className,
> byte[] bytecode)
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> {code}
> with following one:
> {code:java}
> public Class defineClassWithBytecode(String className, byte[] bytecode)
> {
> synchronized (className.intern())
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> }
> {code}
> It is just an idea to quickly check solution.
> Can anybody check and discuss idea? Or even better to fix issue. :-)
> I'm not an expert in concurrency and afraid making changes in such a critical
> place at least before somebody reviewed my idea. So any feedback would be
> appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TAP5-2546) Parallel class loading
[
https://issues.apache.org/jira/browse/TAP5-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15950407#comment-15950407
]
ASF subversion and git services commented on TAP5-2546:
---
Commit 627df8511604bc969af4e59ed34fb9578ed1586d in tapestry-5's branch
refs/heads/master from [~jkemnade]
[ https://git-wip-us.apache.org/repos/asf?p=tapestry-5.git;h=627df85 ]
TAP5-2546: register PlasticClassLoader as parallel capable
PlasticClassLoader does not hold any internal state, so it is able to load
classes in parallel.
> Parallel class loading
> --
>
> Key: TAP5-2546
> URL: https://issues.apache.org/jira/browse/TAP5-2546
> Project: Tapestry 5
> Issue Type: Sub-task
> Components: plastic
>Reporter: Michael Mikhulya
>
> I would like to improve page loading time by improving its concurrent
> execution.
> Here is a first patch related to it: TAP5-2545
> Now the worst place from lock contention point of view is synchronization on
> {{PlasticClassLoader}}. Actually there are two kind of synchronization:
> {{synchronized}} methods in {{PlasticClassLoader}} and {{synchronized
> (loader)}} sections in {{PlasticClassPool}}.
> Recently most class loaders added support for parallel class loading:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=464442
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57681
> If we would like to split global lock, then we can use following trick for it.
> We can substitute code like this:
> {code:title=PlasticClassLoader.java}
> public synchronized Class defineClassWithBytecode(String className,
> byte[] bytecode)
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> {code}
> with following one:
> {code:java}
> public Class defineClassWithBytecode(String className, byte[] bytecode)
> {
> synchronized (className.intern())
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> }
> {code}
> It is just an idea to quickly check solution.
> Can anybody check and discuss idea? Or even better to fix issue. :-)
> I'm not an expert in concurrency and afraid making changes in such a critical
> place at least before somebody reviewed my idea. So any feedback would be
> appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TAP5-2546) Parallel class loading
[
https://issues.apache.org/jira/browse/TAP5-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15948475#comment-15948475
]
Jochen Kemnade commented on TAP5-2546:
--
The fix should work, but I wonder why the methods are synchronized at all. It
was done for TAP5-1650, I'm trying to find out what the actual issue was.
> Parallel class loading
> --
>
> Key: TAP5-2546
> URL: https://issues.apache.org/jira/browse/TAP5-2546
> Project: Tapestry 5
> Issue Type: Sub-task
> Components: plastic
>Reporter: Michael Mikhulya
>
> I would like to improve page loading time by improving its concurrent
> execution.
> Here is a first patch related to it: TAP5-2545
> Now the worst place from lock contention point of view is synchronization on
> {{PlasticClassLoader}}. Actually there are two kind of synchronization:
> {{synchronized}} methods in {{PlasticClassLoader}} and {{synchronized
> (loader)}} sections in {{PlasticClassPool}}.
> Recently most class loaders added support for parallel class loading:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=464442
> https://bz.apache.org/bugzilla/show_bug.cgi?id=57681
> If we would like to split global lock, then we can use following trick for it.
> We can substitute code like this:
> {code:title=PlasticClassLoader.java}
> public synchronized Class defineClassWithBytecode(String className,
> byte[] bytecode)
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> {code}
> with following one:
> {code:java}
> public Class defineClassWithBytecode(String className, byte[] bytecode)
> {
> synchronized (className.intern())
> {
> return defineClass(className, bytecode, 0, bytecode.length);
> }
> }
> {code}
> It is just an idea to quickly check solution.
> Can anybody check and discuss idea? Or even better to fix issue. :-)
> I'm not an expert in concurrency and afraid making changes in such a critical
> place at least before somebody reviewed my idea. So any feedback would be
> appreciated.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
