You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by sebb <se...@gmail.com> on 2014/09/14 15:42:32 UTC
Tomcat BCEL and Commons BCEL
It seems that Tomcat's version of BCEL is diverging significantly from
Commons BCEL.
Is there any mileage in trying to re-organise Commons BCEL so it is
more easily usable by Tomcat?
For example, I gather that Tomcat only uses a small portion of Commons BCEL.
Maybe the Commons code could be divided in some way to reflect this need?
There are probably other projects that just need the read-only parts of BCEL.
Tomcat would presumably still need to change the package name, but
that can be automated as is done for Commons Pool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat BCEL and Commons BCEL
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-09-15 13:32 GMT+04:00 Konstantin Kolinko <kn...@gmail.com>:
> 2014-09-14 17:42 GMT+04:00 sebb <se...@gmail.com>:
>> It seems that Tomcat's version of BCEL is diverging significantly from
>> Commons BCEL.
>>
>> Is there any mileage in trying to re-organise Commons BCEL so it is
>> more easily usable by Tomcat?
>>
>> For example, I gather that Tomcat only uses a small portion of Commons BCEL.
>> Maybe the Commons code could be divided in some way to reflect this need?
>> There are probably other projects that just need the read-only parts of BCEL.
>>
>
> Tomcat needs only
> * super class name
> * interfaces class names
> * class-level annotations (RuntimeVisibleAnnotations attibute)
>
> All the rest are not needed and have been removed. (See how methods in
> ClassParser skip over sections of class file).
>
> In theory, other libraries may want the same and I think it boils down
> to an alternate ClassParser that has the same skip-over behaviour.
>
> (...)
One more thought, regarding future changes to class file format and
corresponding maintenance of the code.
First,
I do not expect changes to generic structure of the class file, nor
changes to the structure of fields and methods. There have been
changes to the constants pool - additions of new constant types, and
changes to Attributes - additions of attributes.
The attributes are OK, they have explicit length field and can be
opaquely skipped.
The constants are bad. They have variable size and the size depends on
the type of the constant. We do not know the size unless we know the
meaning of a constant type code.
Thus when any new constant types are added to the class file format,
someone would have to update the implementation of
Constant.readConstant() method.
Without an update Tomcat will not be able to scan classes compiled
with newer versions of Java.
Second,
There is one other place where Tomcat code scans a class file:
org.apache.jasper.compiler.SmapUtil $ SDEInstaller
It is responsible for writing "SourceDebugExtension" attribute for the class.
Its copyConstantPool() method would need the same update as BCEL
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat BCEL and Commons BCEL
Posted by Konstantin Kolinko <kn...@gmail.com>.
2014-09-14 17:42 GMT+04:00 sebb <se...@gmail.com>:
> It seems that Tomcat's version of BCEL is diverging significantly from
> Commons BCEL.
>
> Is there any mileage in trying to re-organise Commons BCEL so it is
> more easily usable by Tomcat?
>
> For example, I gather that Tomcat only uses a small portion of Commons BCEL.
> Maybe the Commons code could be divided in some way to reflect this need?
> There are probably other projects that just need the read-only parts of BCEL.
>
Tomcat needs only
* super class name
* interfaces class names
* class-level annotations (RuntimeVisibleAnnotations attibute)
All the rest are not needed and have been removed. (See how methods in
ClassParser skip over sections of class file).
In theory, other libraries may want the same and I think it boils down
to an alternate ClassParser that has the same skip-over behaviour.
(In theory, there might be other intermediate states between such
short and full scanning.
If one were to selectively configure a ClassParser, I think that there is
a) whether (field+method) information is needed
b) what class Attributes to parse. There are a lot of those (23 in
Java 8) and most are of no interest.
In that case, what would be a use case?
If class is already loaded by classloader it would be better to just
ask JVM via reflection. There is no need to parse the class file in
that case).
Possible simple optimizations at this step:
a) Stop reading class attributes once "RuntimeVisibleAnnotations" has
been read. It can occur at most once.
(As most classes do not have such attribute, I do not expect much gain here).
b) Do not look for attributes at all (i.e. we may stop reading early)
is class file version is old and does not support annotations.
(I do not expect any gain here, as I think majority of libraries are
compiled with up-to-date java).
The next hurdle is reading and maintaining ConstantPool. Only minority
of those constants are referenced in those structures that we read.
So
a) Maybe there is some further way to optimize constant pool parsing.
Mark has already removed many constant types that we do not need.
One constant type that remains is ConstantUtf8. I wonder whether there
will be some gain in delaying byte[] -> String conversion for UTF-8
data, and what methods there are for that.
(The methods that I know about are DataInputStream.readUTF8() and
static method DataInputStream.readUTF8(DataInput)).
b) JavaClass and other structure classes have a reference to
ConstantPool. As most information in the pool is not needed, it would
be better to not keep it in memory for too long.
I think we are already OK here, as JavaClass object and its data
structures are not cached by Tomcat but released after scanning.
As constant pool indexes are not the information that the caller needs
here, I modified JavaClass in
http://svn.apache.org/viewvc?view=revision&revision=r1624636
http://svn.apache.org/viewvc?view=revision&revision=r1624642
There might be the same change for internal structures of
AnnotationEntry class, but there is really no point, as Tomcat does
not cache them.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Tomcat BCEL and Commons BCEL
Posted by Mark Thomas <ma...@apache.org>.
On 14/09/2014 14:42, sebb wrote:
> It seems that Tomcat's version of BCEL is diverging significantly from
> Commons BCEL.
>
> Is there any mileage in trying to re-organise Commons BCEL so it is
> more easily usable by Tomcat?
Probably not, given how much Tomcat has now removed / changed from the
original.
> For example, I gather that Tomcat only uses a small portion of Commons BCEL.
> Maybe the Commons code could be divided in some way to reflect this need?
I don't see an obvious way to split it without making the Commons BCEL
unmanageable. Feel free to experiment if you want to scratch that itch.
> There are probably other projects that just need the read-only parts of BCEL.
Tomcat needs a lot less than that.
> Tomcat would presumably still need to change the package name, but
> that can be automated as is done for Commons Pool.
BCEL and Pool (and DBCP) are all handled exactly the same way in trunk
(svn copy + package rename) already.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org