search

trifork / erjang

A JVM-based Erlang VM
http://www.erjang.org
Apache License 2.0
725 stars 62 forks source link

Find a way to not load all the function stubs up-front #22

Closed krestenkrab closed 10 years ago

krestenkrab commented 14 years ago

I suspect we spend a lot of time loading function stubs for all function (specialized java.lang.reflect.Method-like things) when Erjang launches. Establish the truth in that statement; and then figure out if we can somehow make that lazy.

Every exported function needs one of these stubs (some subclass of EFun), but perhaps we can install a generic handler which will then replace itself when invoked the first time. Ideally, we should only need to load 1 class per module (until you start calling functions).

krestenkrab commented 14 years ago

I looked at some numbers for some of the modules. 2 samples, application_controller: the main modules takes 47% of the java byte codes; for erl_parse the main module takes only 35% of the java byte code. The more functions a module has, the smaller the fraction is typically "real stuff".

It's an issue for us that we use too much memory on JVM byte codes.

eriksoe commented 13 years ago

I've changed function wrapper generation so that the function classes are simpler. This brings the figures to (for R14A): application_controller: 64% is main module erl_parse: 42% is main module An improvement (and estone numbers weren't affected by the change). At the same time, the cache size was reduced by 15%. Not sure whether Java process footprint has improved though.

krestenkrab commented 10 years ago

I think we'll move this to the day we do InvokeDynamic. Closing for now.