Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 35414 - FileObjects occupy too much memory
FileObjects occupy too much memory
Product: platform
Classification: Unclassified
Component: Filesystems
PC Linux
: P3 (vote)
: 4.x
Assigned To: rmatous
Depends on:
  Show dependency treegraph
Reported: 2003-08-13 15:04 UTC by Jaroslav Tulach
Modified: 2008-12-22 18:55 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Jaroslav Tulach 2003-08-13 15:04:09 UTC
It is necessary to measure the amount of memory
occupied by an instance of AbstractFolder or
AbstractFileObject in order to understand its
overhead and in order to setup some goals for
improving it.

The interesting values are - how much memory
folder and leaf occupies after initialization, how
that changes after some operations (getDate,
add...Listener, etc.) and find out how that could
be improved especially when considering example of
having a directory with 10000 leaf files.

Please write a test using assertSize on a
FileObject, AbstractFileObject.
Comment 1 _ rkubacki 2004-09-24 10:59:50 UTC
I changed summary to better reflect current state - we have AFO
wrapped into masterFS by MultiFileObject instances.

I am going to compute how big are these structures. 

1st observation: o.n.m.masterfs.Delegate keeps both its file change
listener and this listeners wrapped into weak listener. Maybe we can
save one field.
Comment 2 _ rkubacki 2004-09-24 11:17:37 UTC
If I got it right every MasterFileObject takes more than 200 bytes.

MasterFileObject - 24 
 Delegate - 40
  delegate - FO
  secondDelegate - FO
  weakListener - 24 o.o.u.WeakListener.FileChange
   32 o.o.u.WeakListener.ListenerReference
    24 j.l.ref.WeakReference (to source)
  fListener - 16 o.n.m.masterfs.MasterFileObject$FileChangeListenerImpl
 16 (lsnr list) 
  array in lsnr list 
 16 (ResourcePath)
  24 String in ResourcePath
   chars in path
Comment 3 _ rkubacki 2004-09-24 11:38:36 UTC
MultiFileObject are not better. I see ~1500 instances in my IDE, each
one brings >216 bytes and often more (synced ArrayList if there is
some lsnr and HashSet for delegates). At least we should create the
listener list and delegates set of reasonablel size. 10 and 16 are
usualy bigger than we need.

MultiFileObject - 64
 system - FS
 name 24 (String)
  char array in name
 parent - FO
 listeners - synchronized ArrayList
 delegates - HashSet
 weakL = 24 (o.o.f.$Proxy0)
  24 o.o.u.WeakListener.PRoxyListener
   32 o.o.u.WeakListener.ListenerReference
    24 j.l.ref.WeakReference (to source)
 lastAttrcacheName 24 - String
  char array
Comment 4 _ rkubacki 2004-09-24 13:09:19 UTC
And now AbstractFileObject/Folder. For a file w/o listeners it can be
something more than 160 (depending on name length). For a folder with
initialized children it is aproximately 312 + 60 * #children + "char
arrays to keep names of children (are these Strings shared?)" + 4 * #lsnrs

At least do not use Boolean to mark folders, again proper sizing of
listener list can help, map of children is already sized according to
count of found files. Do we need Date? Would it be enough to have long

AbstractFileObject - 56
 system - FS
 name - 24 String
  char array
 parent - FO
 validFlag - boolean
 validRoot - AFF
 children - ~12 bytes overhead array of children
 map - 40 HashMap - only good for folders
  entries array
    reference to AFO 
 listeners - 32 ListenerList
  listenersList - 32 j.u.Collections$SynchronizedRandomAccessList
   list - 24 ArrayList sized to 10 by default
    array of elements
 lock - 8
 folder - 16 Boolean !!!
 lastModified - 24 java.lang.Date

Comment 5 Jaroslav Tulach 2004-10-27 15:15:43 UTC
This is a remainder to you, the owner of this bug, that this issue has P3, is
reported against 4.0 and its target milestone has not yet been set. Please set
the milestone, fix the issue or change its priority by tomorrow. Thank you for
helping NetBeans to get ready for code freeze.
Comment 6 rmatous 2005-09-21 15:32:04 UTC
Fixed in 4.1 by implementing FileBasedFileSystem.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo