openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Linskey" <plins...@bea.com>
Subject RE: SERP vs ASM vs ...
Date Tue, 11 Jul 2006 16:33:20 GMT
Comments inline.

> From experimenting with Kodo and now building the code within 
> OpenJPA, I know that we have a dependency on the SERP 
> open-source project.  I also see where Abe seems to the main 
> contact for support, so maybe we have an "in"
> with the support person.  :-)

Yes; Abe's the primary author of serp. Turns out it actually predates
Kodo; we've been using it since maybe sometime in fall 2000 or so.

>    - *Speed.* Serp is not built for speed. Though there are plans for
>    performing incremental parsing, serp currently fully 
> parses class files when
>    a class is loaded, which is a slow process. Also, serp's 
> insistence on
>    full-time consistency between the low and high-level class 
> structures slows
>    down both access and mutator methods. These factors are 
> less of a concern,
>    though, when creating new classes at runtime (rather than 
> modifying existing
>    code), or when using serp as part of the compilation 
> process. Serp excels in
>    both of these scenarios.
>    - *Memory.* Serp's high-level structures for representing class
>    bytecode are very memory-hungry.

Bear in mind that Kodo only uses serp at compile / class-load time, so
any overhead in terms of time or memory is at worst incurred during
deploy.

Oh, and there's actually at least one exception to the speed issue:
ConstantPoolTable can do some fast / low-memory work to poke around bits
of a class quite efficiently. This is particuarly useful for
annotation-scanning. I think that these algorithms might actually have
been inspired by ASM's equivalents, as it turns out.

>    - *Multi-threaded modifications.* The serp toolkit is not 
> threadsafe.
>    Multiple threads cannot safely make modifications to the 
> same classes the
>    same time.

This is more of a cautionary note than a problem per se. Serp doesn't go
stomping on statics across multiple threads or something; as long as you
don't assume that a Project and the various other classes you can get
from a Project are thread-safe, things work fine. Multi-threaded
bytecode processing has never been a design goal of ours.

> These type of warnings make me a little nervous about the 
> robustness and production-readiness of SERP.  Am I reading 
> too much into this web page?

I'd say you're reading too much into it. Serp's very production-stable;
we've been using it for probably about six years at this point. 

I've never done speed or memory comparisons between serp and ASM, but I
wouldn't be surprised if they're in the same ballpark for
general-purpose usage. Anyone have any knowledge about ASM's speed / mem
consumption?

> Or, should we be looking into "upgrading" OpenJPA to use ASM 
> sometime in the future?  I've experimented with SERP and the 
> programming model seems to be a slightly higher level which 
> makes it easier to interact with.  But, are we paying a price 
> for this ease-of-use?  Just looking for some background 
> information on why SERP instead of ASM.

Personally, I don't see any reason to do so. As you mention, the
programming model is a tad more convenient than most bytecode
frameworks, and of course, the code works and works well. But if there
are compelling advantages to moving to ASM, we should certainly consider
it.

-Patrick
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.

Mime
View raw message