Scott Oaks commented on 12/17/2011:
"I would guess that the compilation itself is not the issue, because we only see a regression for the first deployment and access – when we redeploy and access, the times are the same before and after the JSP integration."
Kin-man commented on 12/28/2011:
"The only thing I can think of is that jsp api and el api classes were repackaged into one jar file, but now they remain as two separate jars."
"Yes; it is additional disk access and parsing of a manifest plus dependencies. Maybe not enough to account for the entire regression, but at least part of it (and the entire regression we're tracking down here is only a few hundred milliseconds...)
How easy would it be for you to package the module back as one jar file so we can drop it into build 15 and test the difference? Then we'd know if it is that, or something else."
"Dhiru and I agreed that it'll make more sense to keep jsp api and el api separate, but instead, to combine the api with the corresponding implementations. I've used the same group and artifact id, so the new jars can be dropped into<GF>/modules directory.
Attached are the 3 new jars. Please drop them into the modules directory (replacing the ones in it). Also remove the following jars from modules
If the benchmark shows improvement, I'll commit the changes, and publish the new artifacts and integrate them into glassfish."
Amit Agarwal 1/6/2012:
"I don't see any improvement with these jar files."
Dhiru on 1/6/2012:
"Can we then infer that the cause of regression was not because of the increase in the number of jar files, because with this change there are 3 less jar files in the modules directory"
"So if it isn't the packaging itself, something else has changed. One thing we discovered in the profile is that web container startup performance has regressed through this path (for deploying a simple hello-world JSP immediately after startup):
ApplicationLifecycle.setupContainerInfos -> ApplicationLifecycle.startContainers -> EnginINfo.getContainer ->
AbstractInhabitantImpl.get -> EventPublishingInhabitant.get -> SingletonInhabitant.get -> AbstractCreatorImpl.get -> ConstructorCreator.initialize -> AbstractCreatorImpl.inject -> InjectionManager.inject -> InjectInjectionResolver.getValue.
In 3.1.2, that last getValue method calls InjectInjectionResolver.getArrayInjectValue; in 3.1.1 it called InjectInjectionResolver.getServiceInjectValue. There is a significant difference in those calls, which makes sense because getArrayInjectValue has to convert a list to an array.
What does it mean that getContainer is now returning an array? Are there actually multiple containers? That would also explain why we see more classes now, which is one reason why we are recommending setting PermSize=64m by default."