harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Prepscius <timprepsc...@gmail.com>
Subject Re: harmony vm as a lib
Date Sat, 02 Jan 2010 05:42:12 GMT

I write to give a small update and ask a couple questions.

The update is: I'm still getting everything static-ified.  It seems
when I enabled the missing kernel + natives, those depended on other
natives which depended on other natives which depended on other
natives and jars etc etc.  It seems I must include pretty much every
library just to get past startup.

I'm now up to "Java_java_io_FileDescriptor_oneTimeInitialization"
HARMONY_CACHE_SET is failing, not sure why, maybe I need to call some
other initialization method somewhere.

So as I'm statically linking libraries as I'm including more and more
dependencies, the executable size keeps on growing.

Here are my current two questions:

1.  Before java initialization, which means after "startup code" has
run, but before I call JNI_CreateJavaVM, process explorer is reporting
that the memory used is already ~5 megabytes.

After initialization (well at the point where it crashes now) process
explorer is reporting that the program is taking ~33 megabytes.

So my question is:  What is the minimum memory foot print of this java
executable?  Anyone know?  Meaning post initialization, pre execute

Is this JVM allocating a whole ton of memory to begin?  If so how can
I change this.  Surely all of those ~28 megabytes (so far) aren't
actually bi-products of little initializations happening everywhere.

2. Does any one know the minimum disk foot print of the executable.  I
guess meaning the base executable plus absolutely essential dlls
(which it seems is turning out to be all of them, but I can't believe
this to be true).


On Sun, Dec 27, 2009 at 8:34 AM, Alexey Varlamov
<alexey.v.varlamov@gmail.com> wrote:
>> At this point I'm trying to get the classes of
>> "luni-kernal-stubs.jar" (which I renamed to kernal.jar)
> Bad idea. This is the point of your failure - those are really
> compilation stubs, just a blueprint of classlib-vm API.
> There are real kernel classes implemented in DRLVM, unluckily buried
> inside the source tree: working_vm\vm\vmcore\src\kernel_classes. You
> should use them instead of luni-kernel-stubs.jar.
>> and "luni.jar" to load.
>> It seems to be getting through a few, and is crashing on java/lang/String.
>> Why? I have no idea as of yet.  I guess that is tomorrow or Sunday.
> Just because String.intern() delegates to kernel classes which are not
> implemented in your setup. All you need is to switch to correct
> kernel.jar, it is normally built as a part of DRLVM.
> Good luck!
> --
> Alexey

View raw message