[antlr-interest] On trees and JavaBeans, part 2: tree creation

[Scott Stanchfield]

> No, I meant you  ;-)
> 
> Your comment that there are extra/more objects to collect in 
> the Carrier/Payload model misses the point because:
> (a) TreeModel-style abstraction is only an adapter - it 
> doesn't remove the need for an actual tree representation 
> which may be a Carrier/Payload model.
> (b) Carrier and Payload are interfaces - they may be 
> implemented by the same object instance hence no extraneous GC.

Not what I'm talking about. My examples assume that you *don't* want to (or
can't) just implement the carrier interface in the actual tree data, like
the case of trying to walk an eclipse AST.

Thus, the carrier approach requires an adapter per actual tree node.

Every time I create a tree I pitch the previous ones (or go through the
risky pooling lease/return dance) which the GC needs to eat.


> I understand Loring to be recommending pooling (via a 
> CarrierFactory) only on platforms that do not have an 
> efficient GC system. This is necessary and once again, I'd 
> argue that the benefits (in performance this time) outweighs 
> the [implementation and usage] cost of the pools.

Again, nothing to do with GC efficiency; everything to do with # objects
created.

Let's take some guesses:

10 refreshes per minute while editing in eclipse
500 AST nodes generated for the class in the buffer
500 carrier nodes generated

Over a 4-hour session, that's 1.2 million AST nodes, and 1.2 million carrier
nodes.

I'd say that's significant work for the GC to collect... 

> If however, you meant Carrier objects then please explain how 
> you might implement an structure that represents trees and 
> separates navigation from data. IOW, explain how you might 
> design an alternative tree structure that a TreeModel-style 
> interface can adapt.

Look at the example code I posted that shows how I adapted a swing GUI into
a Jtree. The GUI components are the tree data, and the ComponentTreeModel
supplies navigation on top of it for the Jtree.

We can do the exact same thing for ASTs in ANTLR.

> Even Eclipse's AST types follow the Carrier/Payload model in 
> some sense. 

They're just a "simple" hetero tree structure.

Later,
-- Scott