Issue Details (XML | Word | Printable)

Key: GLASSFISH-14992
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Critical Critical
Assignee: Richard S. Hall
Reporter: Dhiru Pandey
Votes: 0
Watchers: 11
Operations

If you were logged in you would be able to see more operations.
glassfish

[PERF] Slower classloading with Felix 3.0.6

Created: 03/Dec/10 05:18 PM   Updated: 12/Jan/11 10:28 PM   Resolved: 30/Dec/10 11:38 AM
Component/s: OSGi
Affects Version/s: 3.1_b30
Fix Version/s: None

Time Tracking:
Not Specified

File Attachments: 1. Zip Archive api-exporter-fragment.zip (12 kB) 16/Dec/10 12:15 AM - Sanjeeb Sahoo
2. File Deploy-v1-3.1-felix-2.jps (433 kB) 10/Dec/10 08:49 AM - Santiago Pericas-Geertsen
3. File Deploy-v1-3.1-patched-felix-baseline.jps (435 kB) 10/Dec/10 07:32 AM - Santiago Pericas-Geertsen
4. File Deploy-v1-3.1-patched-felix.jps (431 kB) 10/Dec/10 06:57 AM - Santiago Pericas-Geertsen
5. File Deploy-v1-3.1.jps (448 kB) 09/Dec/10 03:41 PM - Santiago Pericas-Geertsen
6. Java Archive File felix-manifest-parser.jar (394 kB) 21/Dec/10 07:44 AM - Richard S. Hall
7. Java Archive File felix-optimize-resolved-bundles.jar (393 kB) 21/Dec/10 12:29 PM - Richard S. Hall
8. Java Archive File felix-package-space-caching.jar (394 kB) 14/Dec/10 09:34 AM - Richard S. Hall
9. Java Archive File felix.jar (393 kB) 09/Dec/10 09:32 AM - Richard S. Hall
10. Text File gf-dynamic-import-stacks.txt (83 kB) 14/Dec/10 10:57 AM - Richard S. Hall
11. Text File GLASSFISH-14992.txt (1 kB) 07/Dec/10 08:26 AM - Richard S. Hall
12. File perftest.sh (0.4 kB) 08/Dec/10 06:48 AM - Santiago Pericas-Geertsen
13. XML File pom.xml (11 kB) 20/Dec/10 11:28 AM - Santiago Pericas-Geertsen
14. File v1.war (3 kB) 03/Dec/10 05:18 PM - Dhiru Pandey
15. File Wget-v1-3.0.1.jps (431 kB) 20/Dec/10 08:18 AM - Santiago Pericas-Geertsen
16. File Wget-v1-3.1.jps (463 kB) 20/Dec/10 08:18 AM - Santiago Pericas-Geertsen

Image Attachments:

1. wget-security.jpg
(58 kB)
Environment:

All Platforms

Issue Links:
Dependency
 
Duplicate
 

Tags: 3_1-approved
Participants: Dhiru Pandey, dochez, Richard S. Hall, Sanjeeb Sahoo, Santiago Pericas-Geertsen and Tom Mueller


 Description  « Hide

The latest version of Felix 3.0.6 results in slower classloading due to changes in the resolver as compared to 2.0.5. This leads to slower deployment performance - see more details at http://java.net/jira/browse/GLASSFISH-13784

Please use the attached war file to reproduce the issue.

1) Start from fresh domain1

2) With latest Felix:

for i in 1 2 3; do asadmin start-domain domain1; time asadmin deploy v1.war; asadmin undeploy v1; asadmin stop-domain domain1; done

3) Now repeat the same with Felix 2.0.5

Here are some results posted from runs done by Richard:

With Felix 2.0.5:

real 0m2.668s
user 0m0.555s
sys 0m0.106s

real 0m2.688s
user 0m0.549s
sys 0m0.111s

real 0m2.772s
user 0m0.553s
sys 0m0.108s

With Felix 3.0.6:

real 0m3.191s
user 0m0.557s
sys 0m0.114s

real 0m3.461s
user 0m0.559s
sys 0m0.109s

real 0m3.157s
user 0m0.557s
sys 0m0.111s



Sanjeeb Sahoo added a comment - 06/Dec/10 01:03 AM

Richard should look into it. Adding static imports to api-exporter bundle may slow down startup time.


Richard S. Hall added a comment - 06/Dec/10 07:28 AM

Sahoo, we talked about this and I thought we concluded that you would do some experiments to see if static imports would make a difference or not. Did you do them and determine that there was a slowdown? Or do you now want me to do the experiments? I can do them, but you'll have to let me know which packages make the most sense. In a little experiment, I did statically import the packages that were needed to deploy a WAR file and it did seem like it helped.


Sanjeeb Sahoo added a comment - 06/Dec/10 08:39 AM

No, I have not had time to any such experiment yet. It was all theory.
a) We can import all javax packages: to get the list, just take a look at bundles.xml [1].
b) We can import the most frequently needed javax packages.

#b seems like a better approach. If someone tells us what are those packages, we should be able to mention them in v3/core/api-exporter/pom.xml. Someone has to tell us what packages are being resolved dynamically by the test case so that we can import them statically.

[1] http://wiki.glassfish.java.net/attach/OsgiPkgDepAnalyser/bundles.xml


Richard S. Hall added a comment - 07/Dec/10 08:26 AM - edited

Instead of trying to guess which packages to statically import, I monitored which packages were being dynamically imported by api-exporter during server startup and during WAR deployment. This should be sufficient to get some idea if this approach will help. The attached patch adds static imports for the necessary packages.

On my machine, the numbers were inconsistent, but I think there was an improvement. We need someone to do some better performance testing by applying this patch and then testing two different numbers:

1. Stand-alone server startup time to make sure we didn't impact it.
2. The original scenario described in this issue's description.

This will give us an idea if this path is worth pursuing further. If so, then we still need to figure out precisely what should be imported. However, Sahoo's original thought that it should be javax.* packages doesn't appear to be enough, since I am barely seeing any of those for this scenario.


Santiago Pericas-Geertsen added a comment - 08/Dec/10 06:48 AM

Shell script to test deployment performance.


Santiago Pericas-Geertsen added a comment - 08/Dec/10 06:51 AM

With the attached patch that uses Import-Package, I see a 7% improvement on my system when running the perftest.sh script (also attached). The difference between the two versions of Felix was about 8%, so this patch gets us pretty close. I have not tested startup time.


Richard S. Hall added a comment - 08/Dec/10 07:58 AM

Just an FYI: Yesterday I had an idea that may improve the performance of the Felix resolver for dynamic imports. I am going to try to implement it today. If I can get it to work, I will attach a patched felix.jar to this issue for testing.

If this new idea pans out, it may or may not have an impact on whether we decide to follow this current static import plan.


Richard S. Hall added a comment - 09/Dec/10 09:32 AM - edited

The profilers numbers given to me by Santiago seemed to indicate that the resolver was spending a fair amount of time inside a method called calculatePackageSpaces() and more specifically inside there in a method called calculatedExportedPackages(). The resolver is generic and uses LDAP filters internally, this method needs to determine if any imports overlap any exports and it does this by running the LDAP filters over the exported packages. As a result of this, it led me to the idea that I could potentially eliminate filter evaluation by looking in some of my other data structures to get already evaluated results.

The attached felix.jar includes such an optimization. It would be nice if someone could put this through its passes as well as give me some more profiler data if possible. My initial tests were mixed, but I'm still hopeful.


Richard S. Hall added a comment - 09/Dec/10 12:13 PM

Just to follow up to myself, my numbers almost show that this felix.jar is worse than felix 3.0.6...I find that almost hard to believe. I am going to try to see if I can get some profiler numbers myself, but if anyone else could take a look, I'd appreciate it.


Santiago Pericas-Geertsen added a comment - 09/Dec/10 01:29 PM

I see a small improvement of about 2% with the attached felix.jar. However, that seems too close to the variance between runs, so confidence is low. Should this optimization result in less I/O? My guess is that only optimizations that result in less I/O would be provably better.


Richard S. Hall added a comment - 09/Dec/10 01:42 PM - edited

I don't think either approach involve I/O...they are both dealing with metadata that is already in memory, the resolver doesn't do any class loading or disk accesses.

The thing that I find odd was that the profiling numbers Santiago sent me showed that method calculatePackageSpaces() took 12.3% and of that calculateExportedPackages() took 7.7%, which is why I focused on it. My new numbers now show calculateExportedPackages() going to about 0.1%. So, the fact that it is slower doesn't really make sense to me.


Santiago Pericas-Geertsen added a comment - 09/Dec/10 03:40 PM - edited

That is very strange. So in your measurement, calculatePackageSpaces() is now taking 0.1% of the deployment time of v1.war? I'll attach the JProfiler snapshot for your analysis. You can expand the call tree until you see ResolverImpl.resolve(). I'll collect some new profiles with the attached jar for comparison purposes.


Santiago Pericas-Geertsen added a comment - 09/Dec/10 03:41 PM - edited

JProfiler snapshot of GF 3.1 deploying v1.war


Santiago Pericas-Geertsen added a comment - 10/Dec/10 06:57 AM - edited

JProfiler snapshot of GF 3.1 with patched Felix deploying v1.war. Method Felix$FelixResolver.resolve() is down to 5.5% from 13.1%. Unfortunately, we don't see this improvement when running the shell script. Will continue to investigate.


Santiago Pericas-Geertsen added a comment - 10/Dec/10 07:32 AM - edited

NEW BASELINE: JProfiler snapshot of GF 3.1 deploying v1.war. Our old baseline from 11/22 does not appear valid anymore. Generated this new profile using GF 3.1 compiled 12/7 with unpatched Felix. Felix$FelixResolver.resolve() takes 5.1% vs. 5.5% with patch.


Richard S. Hall added a comment - 10/Dec/10 08:39 AM

I am seeing something in my investigation of my patch that I don't currently understand. I'll report back when I do.


Santiago Pericas-Geertsen added a comment - 10/Dec/10 08:49 AM

On more snapshot. This time of GF 3.1 running with the old Felix 2. A quick look at the hotspots (grouped by package) indicates the following changes between Felix 2 and 3:

1) org.apache.felix exclusive time is up 5%
2) org.apache.felix use of java.util classes is up 11%
3) org.apache.felix use of java.lang classes is down 5%
4) org.apeche.felix use of java.util.zip classes is down 1.5%.


Richard S. Hall added a comment - 10/Dec/10 11:09 AM

Ok, I see why my "performance" patch actually reduced performance. Good and bad news.

Long story short, the resolver algorithm in Felix 3.0.6 is incorrectly calculating what packages a module exports for already resolved modules (it correctly calculates the exported packages when it resolves a module for the first time, which is why it still passes the OSGi CT).

The patch (accidentally) corrected this bug. Without going into the details of OSGi dependency resolution, fixing the bug gave the resolver more constraints to check (i.e., more work) for all of the previously missing exported packages, which is why it got slower.

So, I have to apply this patch to Felix no matter what, since it is a bug, which means that we'll still need to investigate other performance improvement possibilities. So far, this list includes:

1. The static import approach we've started to test here.
2. Trying to provide some way for the resolver to cache some of its computations so it doesn't need to recompute all the time.
3. Modify the resolver to be more greedy in resolving so it resolves more in one pass, which won't directly help dynamic import performance, but could possibly reduce overall time.


Sanjeeb Sahoo added a comment - 10/Dec/10 11:17 AM

We can only add static imports for standard APIs like javax.* packages in api-exporter-bundle. We can't add static imports for com.sun.grizzly and all other implementation packages. I actually don't expect them to be loaded via this bundle. Given that they are indeed loaded via this bundle means someone is using Thread's context class loader when they should not be. Well, well, am I surprised by it in EE world?


Richard S. Hall added a comment - 14/Dec/10 09:34 AM

The Felix resolver is stateless, which results in it recalculating some information about already resolved modules across multiple resolve operations. The attached patched version of the Felix framework changes this behavior by caching the package space calculation for resolved modules. I have seen mixed results with it, but I am optimistic.

To run it through its paces, overwrite felix.jar in an existing GF installation with it.

It is not clear to me how much memory overhead this adds, so we might want to perform some memory profiling in addition to performance profiling.


Richard S. Hall added a comment - 14/Dec/10 10:57 AM

Related to determining why we are seeing dynamic imports for implementation packages via the api-exporter bundle, I'm attaching a file that shows the stack trace for each api-exporter bundle dynamic import during server startup and example application deployment. In the file, I list the package being dynamically imported, followed by the thread's stack dump.


Santiago Pericas-Geertsen added a comment - 14/Dec/10 11:12 AM - edited

I see an improvement using felix-package-space-caching.jar. Here are the numbers on my system (5 runs):

[3.1 nightly] mean = 4.9 s (stdev = 0.08)
[3.1 nightly with felix-package-space-caching.jar] mean = 4.57 s (stdev = 0.14)
[3.0.1] mean = 4.28 s

So about 7% faster, but slower than 3.0.1.


Santiago Pericas-Geertsen added a comment - 14/Dec/10 12:20 PM

Richard: Could you provide some explanation as to what is wrong with the traces in gf-dynamic-import-stacks.txt? I see the WebAppClassLoader is in a few of them, but it is unclear to me what the expected behavior should be. Is the parent of WebAppClassLoader not set correctly in these cases?


Richard S. Hall added a comment - 14/Dec/10 12:22 PM

Interesting. The following are the types of numbers I see, which I was comparing to the numbers in the initial issue description, which were also run by me on my machine:

Felix 3.0.x with package space caching:

real 0m2.569s
user 0m0.562s
sys 0m0.111s

real 0m2.855s
user 0m0.561s
sys 0m0.112s

real 0m2.431s
user 0m0.560s
sys 0m0.109s

These numbers compare favorably to my original Felix 2.0.5 numbers, but I guess all I can conclude is that the results on my machine are too variable or something.

I've pretty much done everything that I can think of at this point.


Santiago Pericas-Geertsen added a comment - 14/Dec/10 12:36 PM

The GF 3.0.1 mean in my last comment was incorrect, it's 4.28. So, better, but there's still a difference on my system. Perhaps we should ask Hong to try your latest patch too. I'm running my test on Solaris 10 x86 with JDK 1.6.0_16.


Richard S. Hall added a comment - 14/Dec/10 12:51 PM

I am running on a Mac.

Regarding your other question about the dynamic import traces, I'm only providing the information. I am not really able to interpret whether they are good or bad. We'll need Sahoo for that.


Sanjeeb Sahoo added a comment - 14/Dec/10 07:55 PM

Thanks Richard for generating the DynamicImport triggerring packages for api-exporter module. While some of them look genuine, some of them are not. IMO, TCL should only be used to load application specific classes not application server specific classes, but because of legacy, GlassFish uses TCL to load all kinds of server classes. Let's take a look at package called com.sun.grizzly.http.res in Richard's report. Can anyone explain why one grizzly class (com.sun.grizzly.http.SelectorThread) is loading another grizzly class using TCL? Similarly, we should look at the some of the security packages as well. Same goes for Jasper classes, Jersey classes, etc.


Santiago Pericas-Geertsen added a comment - 15/Dec/10 08:00 AM

Hong collected some data on a Linux/Ubuntu system compare GF 3.0.1 and GF 3.1 with Felix 3, Felix 2 (old felix) and Felix 3 with caching (improve felix):

These are the results read from the output: the time spent for the whole deploy command:
3.0.1 FCS: 4.134s (time from five runs: 4.146s 4.183s 4.173s 4.068s 4.098s)
3.1 b30: 4.909s (time from five runs: 4.821s 4.932s 4.882s 4.811s 5.028s)
3.1 b33: 4.554s (time from five runs 4.539s 4.566s 4.525s 4.500s 4.642s)
b33 with old felix: 4.004s (time from five runs: 4.326s 3.845s 3.790s 4.270s 3.788s)
b33 with improved felix: 4.044 s (time from five runs: 4.025s 4.058s 4.091s 4.058s 3.990s)

These are the times read from the server.log: the time spent in the deployment code (DeployCommand.execute):
3.0.1 FCS: 3.057s (time from five runs: 3.076s 2.927s 3.132s 3.068s 3.084s)
3.1 b30: 3.674s (time from five runs: 3.543s 3.635s 3.855s 3.567s 3.769s)
3.1 b33: 3.598s (time from five runs: 3.573s 3.642s 3.540s 3.539s 3.694s)
b33 with old felix: 2.942s (time from five runs: 3.312s 2.926s 2.806s 2.838s 2.828s)
b33 with improved felix: 3.093s (time from five runs: 3.094s 3.117s 3.071s 3.091s 3.093s)

Deployment times for 3.0.1 and 3.1 b33 with improve felix are very close, so the caching seems to be working.


dochez added a comment - 15/Dec/10 11:30 AM

I spent some time looking into this. The real issue is that we probably need to have two exporter API module (one for the application server, and one for the application). The re-exportation control list for the application server one should be tightly maintained because right now we are breaking encapsulation left and right in the application server. Think about it, any module can load any exported classes using the context class-loader.

Longer term fix would probably require us to have a different set of threads serving the application server versus the application and have no thread-context class loader for the application server threads.

I also looked specifically at com.sun.grizzly.http.res, and it's because a class (SelectorThread.java) located inside grizzly-http module is relying on a class (StringManager) located inside the grizzly-utils module to load a resource located in the originating grizzly-http-module. The grizzly APIs to do this resource loading must be changed from

ResourceBundle getBundle(String packageName) to
ResourceBundle getBundle(String packageName, ClassLoader locator)

where the class-loader should be passed by the originating resource requester code. For instance :

ResourceBundle bundle = StringManager.getBundle("com.sun.grizzly.http.res", SelectorThread.class);


Sanjeeb Sahoo added a comment - 16/Dec/10 12:15 AM

PFA maven module as well as a already built jar. Unzip it in your v3/ workspace and then you can build it by just running: mvn package -f v3/core/api-exporter-fragment/pom.xml. The produced jar (there is already a jar in the zip file) is a fragment bundle which attaches to api-exporter bundle. This fragment optionally imports all EE6 APIs (note EE6 APIs automatically include all SE6 APIs). There is version information missing at this point, but I don't think this is an issue to begin with. Copy the jar to glassfish/modules and restart. See if it makes any difference to perf numbers, as this should reduce number of dynamic imports.

Richard observed that a lot of dynamic imports are happening to non-javax packages. You can easily experiment this by adding those packages in the package list mentioned in pom.xml.


Sanjeeb Sahoo added a comment - 17/Dec/10 12:46 PM

Santiago,

I want someone to try the fragment bundle I attached in my last comment. One needs to do the following:

1) unzip that attachment in your v3 workspace
2) build that module alone. Copy the produced jar to glassfish/modules/ and rerun the perf test. Collect the numbers.
3) The pom.xml lists packages that are optionally imported. Currently it lists all EE6 packages. One can add some non-standard packages there too. Try adding the packages mentioned in Richard's earlier comment and see if it makes any difference.

If you have questions, talk to Richard who is in your timezone.

Sahoo


Santiago Pericas-Geertsen added a comment - 20/Dec/10 07:30 AM

Sahoo: Tried building and copying api-exporter-fragment.jar into the modules directory. Performance is worse by 18%. Here are the numbers:

[3.1] m=4.98 stdev=0.14 (baseline)
[3.1 + api-exporter-fragment] m=5.86 stdev=0.13

Average of 5 deployment runs. Single CPU, Solaris x86 machine.


Santiago Pericas-Geertsen added a comment - 20/Dec/10 08:14 AM

Analysis of as_deploymentScenario benchmark:

(I) These are the steps timed by this benchmark:

start timer
(1) start domain
(2) deploy app
(3) get URL of deployed app
(4) redeploy app
(5) get URL of redeployed app
stop timer

(II) Here are the numbers on GF 3.0.1, 3.1, 3.1 with Felix cache [3.1 fc], 3.1 with Felix 2 [3.1 f2]. Numbers correspond to steps in previous bullet. Percentages from [3.0.1] baseline.

[3.0.1] [3.1] [3.1 fc] [3.1 f2]
(1) 4.51 5.29 (-17%) 5.13 (-14%) 5.36 (-19%)
(2) 3.58 5.09 (-42%) 4.45 (-24%) 4.26 (-19%)
(3) 2.15 2.83 (-32%) 2.52 (-17%) 2.27 (-6%)
(4) 2.55 2.71 (-6%) 2.82 (-10%) 2.77 (-9%)
(5) 0.93 0.98 (-5%) 1.07 (-15%) 0.96 (-3%)
Total 13.72 16.9 (-23%) 15.99 (-17%) 15.62 (-14%)


Santiago Pericas-Geertsen added a comment - 20/Dec/10 08:18 AM

Profiles for step (3) of as_deploymentScenario benchmark. At first glance, main difference is the call to RealmAdapter.isSecurityExtensionEnabled() from WebPipeline.invoke(). See wget-security.jpg attachment.


Richard S. Hall added a comment - 20/Dec/10 09:26 AM

For the api-exporter fragment, you'll need to add some (or all) of the packages from my GLASSFISH-14992.txt patch attachment. Those are the packages actually being dynamically imported. The fragment only includes Java EE packages, which won't have much of an impact since deploying v1.war doesn't trigger dynamic class loads for them.


Santiago Pericas-Geertsen added a comment - 20/Dec/10 11:28 AM

Richard: I added the packages from the attachment and created the attached pom.xml. I see an improvement over having only java packages, but not an improvement over 3.1 without api-exporter-fragment.jar. Here are my results:

[3.1] m=4.98 stdev=0.14
[3.1 + api-exporter-fragment] m=5.86 stdev=0.13
[3.1 + api-exporter-fragment + updated pom] m=5.20 stdev=0.14

Please double check that I updated the pom correctly.


Richard S. Hall added a comment - 21/Dec/10 07:44 AM

The attached felix-manifest-parser.jar file tries a different approach for improving performance by reducing memory allocations and overhead. Previous experience shows that using JarFile to obtain the manifest is very memory inefficient, so this patched Felix uses a custom manifest parser and uses ZipFiles in places of JarFiles.

I see improvement using this version, but as always my numbers vary. Let me know if anyone else sees any improvement.

This patched Felix does NOT include the package space caching, which I'd rather avoid if I could. To use this version, overwrite the existing felix.jar in your GF installation with it.


Richard S. Hall added a comment - 21/Dec/10 08:02 AM

Santiago, regarding your modified pom.xml file, it's not clear to me why all of the escape sequences/line continuations are in there, but they appear to parse ok.

You made a mistake in your edits, since you added javax.management.remote.rmi to the imports since it was in my list, but this was already in Sahoo's list. As a result, in your tests the fragment bundle would have never installed, because it is an installation error to have duplicate imports.

You should modify your pom.xml to remove the second occurrence of javax.management.remote.rmi then try again.


Santiago Pericas-Geertsen added a comment - 21/Dec/10 08:39 AM

Richard: Re-run test after fixing duplicate package. Results are much better,

[3.1] m=4.98 s=0.14
[3.1 + api-exporter-fragment] m=4.22 s=0.05
[3.0.1] m=3.94 s=0.08

About 18% better than current build.


Richard S. Hall added a comment - 21/Dec/10 10:15 AM

Good. That makes sense, since the api-exporter-fragment avoids doing dynamic imports at all. Now we just have to determine if we want to do that and if so with which packages.

I will continue to look into other ways to improve dynamic import resolve performance for the time being.


Richard S. Hall added a comment - 21/Dec/10 12:29 PM - edited

In the felix-optimize-resolved-bundles.jar attachment, I've realized I could optimize how I calculate the package space of already resolved bundles. With this patch, I'm seeing my best numbers so far (without caching state), such as:

real 0m2.575s
user 0m0.560s
sys 0m0.111s

real 0m2.684s
user 0m0.554s
sys 0m0.109s

real 0m2.687s
user 0m0.560s
sys 0m0.113s

As always, my numbers can vary wildly, so I'd appreciate some analysis of this version of Felix too. This patched Felix is independent of my previous version from earlier today, so both should be examined. We can later try a combined patch, if necessary.

As before, overwrite your existing felix.jar with the attached JAR file. Make sure you are starting from a clean GF install (i.e., you don't want the api-exporter-fragment.jar still hanging around).


Richard S. Hall added a comment - 21/Dec/10 12:47 PM

1. How bad is its impact? (Severity)

It is a reasonable regression. We are generally talking 300 to 600 ms on some use cases, but it all adds up over time.

2. How often does it happen? (Frequency)

It happens all the time. It is distributed over all execution, but some use cases are impacted more than others.

3. How much effort is required to fix it? (Cost)

It depends on the adopted solution(s). Some are more difficult than others. There is no single solution and it is unlikely there is a complete solution that will avoid regression in all cases.

4. What is the risk of fixing it? (Risk)

Again, depends on the adopted solution(s). Some change long-standing approaches, so it isn't completely clear that there won't be other ramifications.


Tom Mueller added a comment - 21/Dec/10 12:49 PM

Approved for 3.1 as this is a regression and a release stopper.


Santiago Pericas-Geertsen added a comment - 21/Dec/10 01:11 PM

Latest numbers including felix-optimize-resolved-bundles.jar.

[3.1] m=4.98 s=0.14
[3.1 + api-exporter-fragment] m=4.22 s=0.05
[3.1 + felix-optimize-resolved-bundles] m=4.31 s=0.1
[3.1 + api-exporter-fragment + felix-optimize-resolved-bundles] m=4.08 s=0.12
[3.0.1] m=3.94 s=0.08

Using both methods we are about 4% from 3.0.1. I'll try a run of official benchmark in 4-core machine.


Santiago Pericas-Geertsen added a comment - 21/Dec/10 01:26 PM

Run of as_developerScenario on 4-core Linux box:

[3.1] m=9.79
[3.1 + api-exporter-fragment + felix-optimize-resolved-bundles] m=8.98
[3.0.1] = 8.75

Or about 3% slower than baseline with the optimizations. Given the other numbers that I've seen, it's possible for the Windows numbers to be even better.


Richard S. Hall added a comment - 21/Dec/10 02:10 PM

Santiago, are you planning on running felix-manifest-parser.jar too? I'd like to see if it has any impact.


Richard S. Hall added a comment - 21/Dec/10 02:34 PM

Santiago, why didn't you give a separate breakdown for felix-optimize-resolved-bundles.jar for as_developerScenario?

Regardless, this is all pretty good. I think we can try to start wrapping things up. For me, the patch for custom manifest parsing and resolved bundle optimization are highly likely to go into the next Felix release.

As for the api-exporter-fragment, I think it is less necessary with these other changes. No matter what, I think Sahoo should be involved in a decision on it.


Sanjeeb Sahoo added a comment - 23/Dec/10 09:54 PM

Committed initial version of api-exporter-fragment:
ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -F msg core/pom.xml core/api-exporter-fragment/ packager/glassfish-nucleus/
Adding core/api-exporter-fragment
Adding core/api-exporter-fragment/pom.xml
Sending core/pom.xml
Sending packager/glassfish-nucleus/pom.xml
Transmitting file data ...
Committed revision 44082.

Santiago to update the package list in pom.xml.


Richard S. Hall added a comment - 30/Dec/10 11:38 AM

I have integrated Felix 3.0.7, so I am resolving this bug. Please close if satisfied. Thanks.


Santiago Pericas-Geertsen added a comment - 03/Jan/11 08:26 AM

In order to take full advantage of the api-exporter-fragment we need the following packages in its pom.xml:

Index: pom.xml
===================================================================
— pom.xml (revision 44186)
+++ pom.xml (working copy)
@@ -330,6 +330,25 @@
org.xml.sax; \
org.xml.sax.ext; \
org.xml.sax.helpers; \
+com.sun.enterprise.v3.admin; \
+com.sun.enterprise.naming.impl; \
+com.sun.grizzly.http.res; \
+com.sun.enterprise.security.ssl; \
+com.sun.org.apache.xerces.internal.jaxp; \
+com.sun.org.apache.xalan.internal.xsltc.trax; \
+com.sun.org.apache.xerces.internal.parsers; \
+com.sun.pkg.client; \
+com.ctc.wstx.stax; \
+com.sun.jmx.remote.protocol.jmxmp; \
+com.sun.enterprise.security.provider; \
+com.sun.enterprise.security.auth.realm.file; \
+com.sun.enterprise.security.auth.realm.certificate; \
+com.sun.enterprise.security; \
+com.sun.faces.config; \
+com.sun.jersey.server.impl.container.servlet; \
+org.apache.jasper.runtime; \
+com.sun.xml.ws.transport.http.servlet; \
+org.apache.jasper.servlet; \
resolution:=optional
</Import-Package>
<Bundle-Description>${project.description}</Bundle-Description>

I'll request permission to update this pom on the dev alias.


Sanjeeb Sahoo added a comment - 12/Jan/11 10:27 PM

See GLASSFISH-15532. We no longer need the fragment jar it seems. So removing it from being part of the distribution. It is still there in the build tree just in case we need this functionality some other day.

ss141213@Sahoo:/space/ss141213/WS/gf/v3$ svn commit -m "Issue #14992: Remove api-exporter fragment, as it is not needed any more to optimize startup time" packager/glassfish-nucleus/pom.xml
Sending packager/glassfish-nucleus/pom.xml
Transmitting file data .
Committed revision 44460.