SERP vs ASM vs ...

[Kevin Sutter <kw...@gmail.com>]

Hi,
>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.  :-)

My previous experiences with byte code weaving and generation have shown
that ASM is a very nice, compact package for this type of processing.  And,
some of the wording on the SERP website have me a little concerned:

 Serp is not ideally suited to all applications. Here are a few
disadvantages of serp:

   - *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.
   - *Multi-threaded modifications.* The serp toolkit is not threadsafe.
   Multiple threads cannot safely make modifications to the same classes the
   same time.
   - *Project-level modifications.* Changes made in one class in a serp
   project are not yet automatically propogated to other classes. However,
   there are plans to implement this, as well as plans to allow operations to
   modify bytecode based on specified patterns, similar to aspect-oriented
   programming.


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?
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.

Thanks,
Kevin

Re: SERP vs ASM vs ...

[Abe White <aw...@bea.com>]

> 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?

Though I haven't used it, based on its architecture I would guess  
that ASM is significantly faster and less memory-hungry.  However,  
given that:
- Our code using serp works.
- It's easier to work with serp.
- Performance is not of primary concern at dev time.
- The cost of the little runtime bytecode processing we do is  
amortized over the life of the app.
I would put an "upgrade" to ASM way, way down on any OpenJPA TODO list.

If you're interested in bytecode processing, Patrick, Marc, and I  
were just discussing a bytecode-related project we'd really like to  
see someone work on once OpenJPA stabilizes...
_______________________________________________________________________
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.

RE: SERP vs ASM vs ...

[Patrick Linskey <pl...@bea.com>]

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.