Well, maybe.  For integers, yes there probably are.  You can save much
more space by inlining the custom data structure into the hash table
entries as well, and obviously that would not pre-exist.

Assuming you want to just inline ints... for ArrayList, the complexity
of an extra dependency on some third-party code is probably not worth
saving the couple dozen lines of code to do this on your own.  The
HashMap will be more complex, and may be worth the new dependency.

Dynamic memory management is not magical in C.  It uses data structures
to work, just like anything else.  Those data structures are typically
stored in the bytes directly before the memory address that's returned
to you from a call to malloc.  You are assuming that when you write
"malloc(8)", that requires 8 bytes of memory.  In reality, it requires
about twice that amount, depending on the malloc implementation.  
Ignoring this makes your comparison unreliable.

Incidentally, I'm still ignoring malloc overhead from memory
fragmentation.  This overhead won't show up in a simple test program,
but will become larger over time in a long-running application,
generally asymptotically approaching a constant proportion of the total
memory requirement.  Modern malloc implementations are pretty good, so
if you wanted to include this, you'd generally assume this memory is
about 20% or so of the actual memory in use.  This is worth mentioning,
because this fragmentation would not be present in Java, in which
defragmentation is generally a side-effect of garbage collection.

Okay, let's get more specific.

I'll assume you use a straight-forward implementation of a general-
purpose hash table written in C.  A hash table will require a set of
buckets, and a linked list of data for each bucket.  On a 32-bit
machine, that's about 8 MB divided by the load factor, for the bucket
heads.  The linked list for the data will contain a pointer to the data
itself, a pointer to the key, and a pointer to the next piece... plus
possibly a cached hash value, but we'll ignore that by assuming you've
chosen an implementation that opts for mem0ory compactness instead of
performance.  That is an extra twelve bytes per entry of visible
overhead, plus about eight bytes per entry of memory management
overhead.  You'll need to dynamically allocate space for the keys, so
that's an extra 4 bytes of visible memory, plus 8 bytes of allocation
overhead.  Assuming a load factor of 2, that brings us to 4 MB
+ (n * 20) + (n * 12), which is a total of 68 MB of overhead for the
hash table.

You can eliminate about 32 MB of that 68 MB by writing your own hash
table, in which case you could inline the data and keys into your hash
entry structure and save the pointers and dynamically allocated keys.  
Similar savings can be had by using C++ templates, and would be expected
in TR1's STL hash structure for example.

So we have an additional overhead of either 68 MB or 36 MB, depending on
your implementation choices.  The total for C is either 100 MB or 68 MB,
not counting some negligible other sources of memory requirement.

So let's take the answer to be 68 MB.  In Java, if you similarly write
your own data structures to inline the data, you'd use an additional 16
MB on top of that, for a total of 84 MB.  Leaving space for the garbage
collector to work, you might expect 128 MB to be sufficient (remember
that we already accounted for about eight bytes per object that aren't
needed in a Java garbage collector since there's generally no explicit
free list, so we don't need to double it).

Or let's take the answer to be 100 MB if you don't want to write your
own hash table.  In Java, you'll get an additional 48 MB, for a total of
148 MB.  Make that about 200 MB for reasonable garbage collector
performance (same note about not needing the overhead to keep a free
list).

Or, if you want to use an ArrayList of Integer in Java instead of
managing your own int[], then the memory requirement goes up to 188 MB,
or maybe 256 MB for reasonable gc performance.  There has been no C
equivalent proposed for such a design, but it would probably require
about 124 MB of memory (similar methods).

So, overall, it appears that Java requires about twice the memory of C
for all possible design alternatives.  C++ shows a considerable
advantage, though, in that you can use STL data structures vector and
TR1's unordered_map, and get the 68 MB result without having to re-
implement anything.