commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [classscan] Metadata API discussion
Date Sat, 09 Jun 2012 07:39:30 GMT
Hi folks, quick reply from vacation :)


@sebb: yes correct. I was just thinking too complicated. We use the interface only for keeping
the metainfo, and not in the metainfo itself. So it should itself not blow up the mem. So
+1 for the interface.

There are 2 important consideration options left:

a.) Store the information we get from BCEL/ASM directly in the meta-info instances.

b.) Take the information we get from BCEL/ASM and store them e.g. in a SingleLinkedList or
array. 

Which one is more effective also has to do whether BCEL/ASM throw away their information after
they pass it to us or if they keep it internally for later reuse. If they store the information
anyway, then  a.) is better - otherwise we should do b.)



LieGrue,
strub


----- Original Message -----
> From: "Honton, Charles" <Charles_Honton@intuit.com>
> To: Commons Developers List <dev@commons.apache.org>
> Cc: 
> Sent: Friday, June 8, 2012 5:47 PM
> Subject: Re: [classscan] Metadata API discussion
> 
> In on my MacBook, I get the following counts for running just the unit
> tests:
> 
> Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527)
> Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode)
> 
> Cache:    1
> BootstrapClassLoader:    1
> WeakConcurrentHashMap:    1
> MetaUrlClassLoader:    2
> HashWeakReference:    5
> FileClassLocation:    5
> PrimitiveClass:    9
> JarClassLocation:    27
> SortedReadOnlySet:    38
> BcelEnumProperty:    296
> BcelProperty:    740
> AnnotationMap$1:    3217
> BcelAnnotation:    3417
> BcelClass$1:    9251
> DeferredMetaClass:    13620
> BcelClass$3:    18232
> BcelClass$2:    26096
> BcelClass:    26774
> ArrayMetaType:    33275
> ReadOnlySet:    54240
> BcelField:    110983
> BcelMethod:    231549
> BcelParameter:    264572
> ClassMetaType:    607104
> AnnotationMap:    633878
> 
> Regards,
> 
> chas
> 
> 
> On 6/7/12 5:27 PM, "James Carman" <jcarman@carmanconsulting.com> 
> wrote:
> 
>> There can be quite a few if you have to have them for every class,
>> interface, annotation, method, field, etc.  Then again if you just reuse 1
>> adapter object all the time it wouldn't be that bad. You would just have
>> to
>> let users know that they cannot maintain references to those objects after
>> scanning is complete.
>> On Jun 7, 2012 8:10 PM, "sebb" <sebbaz@gmail.com> wrote:
>> 
>>>  On 7 June 2012 21:11, James Carman <james@carmanconsulting.com> 
> wrote:
>>>  > On Thu, Jun 7, 2012 at 3:56 AM, sebb <sebbaz@gmail.com> 
> wrote:
>>>  >>
>>>  >> Not sure I follow this. Why would an interface use extra 
> memory?
>>>  >> I can see that it might add a bit more to the static size of a 
> class,
>>>  >> but why would it add more to each instance of a class that 
> uses it?
>>>  >>
>>>  >
>>>  > It's not the interface itself.  It's the fact that you 
> have to have
>>>  > more objects loaded into memory when you use the interface-based
>>>  > approach.  For example, if BCEL has some object that represents a
>>>  > class' metadata, then we'll have to put some 
> "adapter" object in front
>>>  > of it that implements our metadata API interface and knows how to
>>>  > speak BCEL-speak to extract the information.
>>> 
>>>  Yes, but again, surely there won't be all that many such objects?
>>> 
>>>  I think some tests should be done of the two approaches before
>>>  deciding to abandon the interface-based design.
>>> 
>>>  > 
> ---------------------------------------------------------------------
>>>  > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>  > For additional commands, e-mail: dev-help@commons.apache.org
>>>  >
>>> 
>>>  ---------------------------------------------------------------------
>>>  To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>  For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message