Chained put() calls on a builder cause stack overflow very quickly in some environments

[GoogleCodeExporter]

This is not necessarily a bug, per se, in collections, but chaining calls
can cause a stack overflow, and in some environments it happens with
relatively few calls.

Getting a stack overflow during the compilation phase, particularly when
failure is highly dependent on the environment but it not necessarily
related to memory is a very confusing and difficult to debug problem. I
recommend that documentation for the builders make clear note of the
constraint, since at present they mainly demonstrate the ease of using
chained calls.

I haven't had time to do extensive tests to find the cut-off point, but
here are some notes from my experience:

-- With Sun's 1.6 and 1.5 compilers, stack overflow occurs somewhere below
200 chained put() calls on Windows XP using ImmutableBiMapBuilder with an
enum for both keys

-- Changing heap and other memory settings to very high values (up to 1GB
for some settings) does not resolve the problem

-- The same code compiles with Sun's 1.5 compiler on Linux systems without
any changes to default memory settings. JDK 1.6 was not tested on Linux for
this code

-- The same code compiles within Eclipse without any changes to default
memory settings. This causes a large part of debugging confusion

-- Although in retrospect it is clear that the stack-based JVM could have
problems in this respect, I would argue the busy programmer is quite
unlikely to consider alternatives to a huge chain when all the examples
tout the readability

-- "Functional is the New OOP" Observation: This is a great chance for
people unfamiliar with ideas such as tail call recursion to learn what it
is all about

-- "I Will Drink Your Milkshake" Observation: Presumably non-stack JVM-like
environments, such as Dalvik, do not suffer from this condition. This
brings interesting thoughts to mind about why Google wrote Google
Collections in the first place ;-)

Original issue reported on code.google.com by gco...@gmail.com on 8 Jan 2008 at 4:02

[GoogleCodeExporter]

Thanks for the report.

I believe there is no action for us to take on this issue; javac's default 
settings
are apparently poor on XP; you can remedy this with a -J-Xss2m or whatever 
value you
like.

Original comment by kevin...@gmail.com on 8 Jan 2008 at 6:46

• Changed state: WontFix

[GoogleCodeExporter]

Isn't it a documentation defect?

Original comment by gco...@gmail.com on 8 Jan 2008 at 6:48