This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [boehm-gc] Import 6.3 alpha 1


Jeff Sturm wrote:
> On Tue, 29 Jul 2003, Ranjit Mathew wrote:
> 
>>    http://gcc.gnu.org/ml/java/2002-06/msg00073.html
>>    http://gcc.gnu.org/ml/java/2002-06/msg00252.html
>>    http://gcc.gnu.org/ml/java-patches/2002-q2/msg00490.html
>>
>>AFAICT, this is still not integrated into libgcj.
> 
> 
> That patch was far from perfect for reasons I outlined, though I had hoped
> more ideas would emerge to lower the costs of scanning roots.  One
> approach is reducing the size of the static data areas generated by gcj.
> Another is to scan static data selectively, with GC_exclude_roots or some
> other technique, as in the patch you referenced.
> 
> There would be other benefits to shrinking static data, but it seems
> difficult given the current class layout.  If class data used a
> position-independent encoding, much of it could perhaps move to read-only
> sections.  But certain members of the class record (e.g. string table)
> will probably always have to be initialized at runtime.

That seemed to be what Bryce wanted to do:

    http://gcc.gnu.org/ml/java/2002-06/msg00111.html

But again, AFAICT, it's not been implemented yet.

Now that Bryce shows up on the list every now and then,
maybe he'll find himself filled with the sudden
urge to implement something like this. ;-)


>>Could this not help the issue raised in frequent
>>messages on the GCJ list complaining about almost
>>unbounded heap growth like, say, this one:
> 
> 
> The root set is in part responsible for determining the frequency of
> collection.  Fewer collections result in a larger heap.  But I'm unsure
> that root set size can alone be responsible for *unbounded* heap growth.

I was not implying that - merely that allowing more collections
to run *might* help reclaim more heap and *perhaps* would
lead to a slower heap growth. :-)


> That said, a patch like this could also avoid DYNAMIC_LOADING bugs
> on certain platforms.  ISTR win32 having some trouble in that area.

Hans had mentioned this recently. I looked through
"boehm-gc/include/gcconfig.h" in the current CVS and
AFAICT, DYNAMIC_LOADING is *not* defined for Win32
even though "boehm-gc/dyn_load.c" seems to define
GC_register_dynamic_libraries( ) for Win32. On the
other hand, Boehm-GC is not built as a DLL in libgcj
for Windows (so far).

Ranjit.

-- 
Ranjit Mathew          Email: rmathew AT hotmail DOT com

Bangalore, INDIA.      Web: http://ranjitmathew.tripod.com/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]