Re: Plans for 2.8 - GNOME Managed Language Services?


> > > It gets more interesting when memory becomes an issue. Managed code
> > > tends to consume large amounts of memory because the garbage collection
> > > is usually a very low priority thread so as to not affect performance
> > > too severely. However when memory runs low, the priority of the garbage
> > > collection thread is usually increased to compensate - thats when
> > > performance can take a big hit - you either end up in swap or garbage
> > > collection consumes much more cpu. These memory issues have plagued
> > > managed code in the past and contributed to the downfall of Java OS. I
> > > would like to know how Mono compares in this respect.
> > 
> > As I mentioned before, one big advantage that the ECMA CLI has over the
> > JVM is that they support "value types".
> > 
> > Value types are your ints, your longs, your byte blobs and they are
> > equivalent to C "structs".  That means that there is no object
> > overhead.  Arrays of value types are contiguous in memory and these
> > guys can live on the stack.
> I guess your the expert here, but I'm fairly sure that the JVM does this
> too. If you pass an int value to a method, it's not going to be
> converted to an Object. Maybe Mono allows you to define new value types,
> or maybe you are talking about the equivalent of C++ copy-by-value for
> objects.

Yes, those are fine (they are not when you mix int and their class
which is the boxed representation).

The ones that are not are for example:

	struct Point {
		int x, y;

	Points [] points = new Points [n]

In C# you get a blob of contiguous n * 2 bytes, in Java, you have to
declare a class, and you get something like:

	[vtable pointer]
	int x
	int y
	[vtable pointer]	
	int x
	int y

Repeated n times.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]