harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Regis <xu.re...@gmail.com>
Subject Re: harmony vm as a lib
Date Mon, 04 Jan 2010 04:13:35 GMT
On 2010-01-02 13:42, Tim Prepscius wrote:
> Greetings,
> 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.

It requires hyluni.dll from classlib.

> 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
> code.

I think the minimum memory foot print of executable java not only include JVM 
itself but also some classes needed by JVM when starting. Even to run a 
"HelloWorld" program, hundreds of classes will be loaded and also native dlls 
required by them, will you also static link them together?

> 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).
> -tim
> 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

Best Regards,

View raw message