List Info

Thread: bjam memory usage




bjam memory usage
country flaguser name
Germany
2007-09-14 03:41:29
Currently, running the boost regression tests makes bjam use
an impressive 
amount of 1273MB (!!!) of memory on my system.

I know there have been discussions of this excessive memory
usage in the 
past. Among other things, using some special memory
management library was 
discussed, is this still being pursued?

Markus

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: bjam memory usage
user name
2007-09-14 03:55:17
Markus Schöpflin wrote:

> Currently, running the boost regression tests makes
bjam use an impressive
> amount of 1273MB (!!!) of memory on my system.

What are the exact command line options to bjam. Trunk or
RC? Does
this seem like a new problem?

- Volodya


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Re: bjam memory usage
country flaguser name
Germany
2007-09-14 04:19:44
Vladimir Prus wrote:
> Markus Schöpflin wrote:
> 
>> Currently, running the boost regression tests makes
bjam use an impressive
>> amount of 1273MB (!!!) of memory on my system.
> 
> What are the exact command line options to bjam.

/vol2/boost/boost/tools/jam/src/bin.osf/bjam --v2 
-sBOOST_BUILD_PATH=/vol2/boost
-sBOOST_ROOT=/vol2/boost/boost 
hp_cxx-71_006_tru64 hp_cxx-65_042_tru64 -d2 --dump-tests 
-sBZIP2_INCLUDE=/usr/local/include
-sBZIP2_LIBPATH=/usr/local/lib 
-sZLIB_INCLUDE=/usr/local/include
-sZLIB_LIBPATH=/usr/local/zlib 
--build-dir=/vol2/boost/results

>Trunk or RC? Does

Trunk. Is there a current RC branch at the moment?

> this seem like a new problem?

No, bjam has always used insane amounts of memory when
running the 
regression tests, it's just more exaggerated because of the
increased 
amount of tests since 1.34.

Markus

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Re: bjam memory usage
user name
2007-09-17 09:42:14
Rene Rivera wrote:

> Dave mentioned he might look at why it crashes when
using boehmgc. But 
> as we all know he's a busy person  If any
one else is brave enough, 
> they can try it out with the svn bjam version (3.1.15),
just by adding 
> --gc when building bjam.
> 
> NOTE; Using boehmgc does help, when I run with it, it
does use less 
> memory. It just crashes at some point :-(

I have built a version of bjam linked against boehm gc 7.0.
When this 
version is run, it get tons of  complaints from the gc:

GC_debug_register_finalizer called with non-base-pointer
0x8168fe0
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
...

Maybe this rings a bell with someone on what might be
wrong?

Markus

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: bjam memory usage
country flaguser name
Germany
2007-09-17 09:42:14
Rene Rivera wrote:

> Dave mentioned he might look at why it crashes when
using boehmgc. But 
> as we all know he's a busy person  If any
one else is brave enough, 
> they can try it out with the svn bjam version (3.1.15),
just by adding 
> --gc when building bjam.
> 
> NOTE; Using boehmgc does help, when I run with it, it
does use less 
> memory. It just crashes at some point :-(

I have built a version of bjam linked against boehm gc 7.0.
When this 
version is run, it get tons of  complaints from the gc:

GC_debug_register_finalizer called with non-base-pointer
0x8168fe0
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
GC_debug_register_finalizer called with non-base-pointer
0x8161f78
...

Maybe this rings a bell with someone on what might be
wrong?

Markus

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

bjam Build question
country flaguser name
Canada
2007-09-17 14:31:44
Hello,

I am trying to rebuild Bayes++ using bjam (on my intel based
mac  
running OS X 10.4.8), however I get the error below.  Is
bjam failing  
to find gcc?  Can you provide any other advice?

By "rebuild", I mean that I have built Bayes++
before on the same  
machine, and am now having isolated problems instantiating a
formerly  
functional class in Bayes++, and thought somehow my compiled
library  
may have gotten corrupted.

Thank you,
Yon



[Mon Sep 17|yon|/Developer/YV-dev/Bayes++] bjam --v2
-sBOOST_ROOT="../ 
boost_1_33_1"
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/feature.
jam:431:  
in feature.validate-value-string from module feature
error: "gcc" is not a known value of feature
<toolset>
error: legal values:
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/property
.jam:250:  
in validate1 from module property
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/property
.jam:273:  
in property.validate from module property
/Developer/YV-dev/boost_1_33_1/tools/build/v2/tools/builtin.
jam:176:  
in variant from module builtin
project-root.jam:7: in modules.load from module
Jamfile</Developer/YV- 
dev/Bayes++>
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/project.
jam:306:  
in load-jamfile from module project
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/project.
jam:68:  
in load from module project
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build/project.
jam:164:  
in project.find from module project
/Developer/YV-dev/boost_1_33_1/tools/build/v2/build-system.j
am:136:  
in load from module build-system
../boost_1_33_1/tools/build/v2/kernel/modules.jam:259: in
import from  
module modules
../boost_1_33_1/tools/build/v2/kernel/bootstrap.jam:153: in
boost- 
build from module
../boost_1_33_1/boost-build.jam:12: in module scope from
module

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Re: bjam memory usage
country flaguser name
United States
2007-09-26 09:10:13
Vladimir Prus wrote:
> Markus Schöpflin wrote:
> 
>> Currently, running the boost regression tests makes
bjam use an impressive
>> amount of 1273MB (!!!) of memory on my system.
> 
> What are the exact command line options to bjam. Trunk
or RC? Does
> this seem like a new problem?

Hardly new. I reported several times that bjam took ~1GB for
1.34.x
runs. bjam has been like that for years.


Regards,
m
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
Re: bjam memory usage
country flaguser name
United States
2007-10-03 11:53:13
on Mon Sep 17 2007, Markus Schöpflin
<markus.schoepflin-AT-comsoft.de> wrote:

> Rene Rivera wrote:
>
>> Dave mentioned he might look at why it crashes when
using boehmgc. But 
>> as we all know he's a busy person  If any
one else is brave enough, 
>> they can try it out with the svn bjam version
(3.1.15), just by adding 
>> --gc when building bjam.
>> 
>> NOTE; Using boehmgc does help, when I run with it,
it does use less 
>> memory. It just crashes at some point :-(
>
> I have built a version of bjam linked against boehm gc
7.0. When this 
> version is run, it get tons of  complaints from the gc:
>
> GC_debug_register_finalizer called with
non-base-pointer 0x8168fe0
> GC_debug_register_finalizer called with
non-base-pointer 0x8161f78
> GC_debug_register_finalizer called with
non-base-pointer 0x8161f78
> ...
>
> Maybe this rings a bell with someone on what might be
wrong?

Hans Boehm has this to say about it:

  The message means the GC_debug_register_finalizer was
passed an
  address that at was at the wrong offset from a GC
allocated object.
  It should normally be at a fixed nonzero offset, since it
should be
  passed an object allocated by GC_debug_malloc, which adds
a header
  with debug information.

  The call stack at the call to GC_err_printf might well be
  interesting.

  Typically, you would be calling GC_MALLOC and
GC_REGISTER_FINALIZER
  with GC_DEBUG defined to get here.  An inconsistent
GC_DEBUG setting
  for different compilation units might do this.  IObj and
base in
  GC_debug_register_finalizer would probably have to have
the same
  value for this to be the case.

  This error by itself is probably not
  fatal. GC_debug_register_finalizer computes the right
object address
  anyway.  The real problem may be elsewhere.

Still, it seems worth investigating.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-cons
ulting.com

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build
[1-8]

about | contact  Other archives ( Real Estate discussion Medical topics )