Propose adding opage/inplace object instance to the language
First, for the eager, what this may solve:
1) Much faster JVM because the garbage collection will kick in much less often
2) Much small memory foot print for java application.
3) Provide better scope control (more on this later)
4) Provide faster object copy (something like: deep copy speed of shallow copy)
5) Predictable finallization of object destructor
Please provide more if you see more.
What is the proposal:
First, I would like to say that this is an idea that is not completely thought out. That means it's not perfect, and needs your inputs and other's input to get it there. So please don't just say that does not work because of this, or of that, but add/change/modify it to make it better.
Java have 2 generate types of data: native and object. Native data are interger, float, double, char, etc. Object instances are instances of classes and arrays. Native data is beautiful in a sense that it does not need garbage collected. This means you can declare as many as you want, and at the end of the function call, it will be easily discarded without any problem. Object instances will not be discarded easily like this, except a very smart compiler can detect if the object is not passing around outside of a function/subroutine, then it can be discarded instantly too (except threading, or things like JFrame).
So, to provide the advantage of native data to the object instances, I propose a new keyword to the langage: opaque (or whatever better term). This keyword will go before a variable's declaration:
ex:
opaque MyClass myobj;
opaque MyClass2 myobj("constructor param1", ect...);
Think of opaque objects as C++ object, and currently objects (allocating with new operator) as C++'s pointer. It does not need "new" to allocate a new one.
The functionally of opaque objects will be the same as that of C++ objects. At the end of the function, it will be discarded as that of other native variables.
You cannot use assignment operator with these ("=" without the double quote). You have to use a function:
myobj.copyFrom(myobj2);
This will be memory copy which is much faster (shallow copy, but if there's any opaque member inside of myobj2, it will be copied too). This provides a semi deep copy functionally. Some constraint must exist here. Such as whether can myobj2 be a handle or must it be an opaque object. If it can be a handle, what if it's null, that would generate runtime exception.
Another way would be java.lang.System.copyObject(obj1, obj2);
This is fine, but it's little bit long and coders may not want that. Another way is to use "=", but this may lead to confusion (does it?). The copyFrom can also be override and to throw exception (such as IO class).
With this, you can control the scope of your object well because its not passing around globally like "new" object (this is a major goodness of java, but also a major problem of it). With the new type of object, you can control this totally. Having both the benefit, and can also choose to avoid it if needed.
Most object would not need to be dynamic object (using new). So, the memory foot print will be very small without frequent garbage collection. You can argue that memory should not go up either case. True, but in reality, unless you call garbage collection all the times, there's always the fluctuation of memory up and down (due to objects not discard by gc() and then discarded). You then can argue that memory foot print could actually go up. True, but not much. This is due to the fact that an object will exist to the end of its scope before it can be collected (such as the end of a function or the end of a block). This is very temporary for current operation/object. Also, you can switch to dynamic object if this is a big issues. Using clear scope, you can also limit this successfully in some cases (declare opaque object instance inside { .. } where it's only used).
There you go. Please contribute your ideas. If this proves to be a great feature of the language, please raise your voice, and hopefully someday it will be incorporated into the language.
[4236 byte] By [
vy_ho] at [2007-9-30 15:24:46]
> First, I would like to say that this is an idea that
> is not completely thought out.
No kidding.
You give the distinct impression that you don't know the difference between heap and stack allocation, you misuse the terminology dreadfully, and the rest of your argument is riddled with fairly deep misunderstandings.
> Please contribute your ideas.
My idea, well, more an opinion, is that this would add nothing of value to the language. If you're convinced I'm wrong, I suggest you write up an RFE or JCP draft.
Dave.
It's nice to get a feedback. But sadly, the feedback was not a feedback, but a ridicule. If you don't mind, please tell me:
1) what heap and stack has anything to do with this?
2) What part is misunderstanding and why?
3) Why it does not add value to the language.
4) Why would write a RFE or JCP draft would convinced me of anything
5) Why that's the best option to just get convinced? (seems alot of work to just get convinced don't you think?)
6) Can you go over point by point, which of my suggestion is flawed?
7) Which terminology is misused? Why is that so? Can it be changed to another term? Or since I suggested this (I don't know if I am the first), do I have the right to call it whatever I want? Who came up with the Java name in the first place, and why coffe has anything to do with programming?
Thanks.
vy_ho at 2007-7-5 22:30:22 >
> But sadly, the feedback was not a feedback, but a ridicule.
That was not ridicule. You don't qualify for ridicule. I'm just pointing out that you have no clue what you're talking about.
> 1) what heap and stack has anything to do with this?
Variables local to a function get allocated on the stack. Objects get allocated on the heap (although their references tend to get allocated on the stack).
> 2) What part is misunderstanding and why?
Pretty much all of it.
Because you're ignorant ?
> 3) Why it does not add value to the language.
One of the strong points of Java is the strictly GC memory model.
> 4) Why would write a RFE or JCP draft would convinced me of anything
> 5) Why that's the best option to just get convinced?
> (seems alot of work to just get convinced don't you
> think?)
Convince you ? I don't need to convince you; you're obviously enamoured of your crappy idea. But if you intend to persuade anyone else that it's a good idea, yammering on in the Java Forums won't get you anywhere; you need to put this sort of change through the JCP (and fat chance of getting anywhere).
And if you want a new feature in the language which will potentially cause problems for everyone concerned, it's only reasonable to expect a bit of effort from you to go about introducing it. Or do you think we should write it for you ?
A rule of thumb - if you don't know how to create a compiler to implement your new feature, you're not qualified to comment on the value of that new feature. If you are qualified to implement such a compiler, we'll listen to you when you've done so.
> 6) Can you go over point by point, which of my suggestion is flawed?
No. I really can't be arsed. I actually don't care that much, because you're so obviously talking ********.
> 7) Which terminology is misused? Why is that so?
Here's an example:
"Java have 2 generate types of data: native and object."
Just SO wrong.
Again, because you're ignorant ?
> Can
> Who came up with
> the Java name in the first place
Who cares ? Gosling or Sun marketing.
>, and why coffe has
> anything to do with programming?
Please tell me you're kidding.
You don't know the terminology, you don't have the faintest idea how the Java memory model works, you think GC is a bad idea. I'm guessing you're a bad C++ programmer who's transferred to Java and things that he's a bad Java programmer because of "missing" features from C++.
Give me a single reason why anyone would care what you think.
Dave.
First off, I want to say that some of the words I used was incorrect. I think if someone can understand it, then that's fine to me.
On the JCP, I think talking to people first, like this forum. Then gather ideas, discussion, then if it's any good, then go to the JCP or whatever if needed. So say going straight to the JCP to propose something is very immature.
To go to the points you pointed out, on the heap and stack. Who care what get allocated where. That's your way of doing it. Did you ever program in c++? If you can copy an object, using memory copy, then that's what I am talking about. It points out that's possible. I am not saying that's the only way of doing it.
My suggestion above does not violate any GC memory model. Maybe you did not read it careful enough. And what memeory model? Did you know that GC memory model was changed lately? Mind you, anything could get changed, and get better, if it can. I think you better read my suggestion again, think hard, and think why it's possible to create a GC that can do this.
About convincing. Unless you're the one that is ignorant, helping someone else to clear his/her point, or adding valuable point is the opposite of ignorant. I do not "yammering" on this forum. If my idea is bad, I'll take it as bad with constructive comment. That's all fine. This is where people talks and contribute idea. It's called a forum. My intention was to get constructed comment, not like yours. It doesn't matter it's crappy idea or not. You are the one who mention about "convinced" in the first place.
I have to disagree with your rule of thumb. That's called ignorant. Anyone can contribute idea. The ignorant one ignore them. Idea can be good or bad, but out of many ideas, there'll be a good one or two. Even though my idea could be bad. That's why I put it up here for people to discuss it.
Saying Java generates native and object data. That could be wrong, but if someone could understand it, that's fine by me. If you don't understand it, then don't say that's wrong, because you don't have a clue of what's wrong and right. If you do, yes, you can pick on me for that. I am ok with that. But my point was that when you said something, then point out what it is, and why it is so. Even in this case, you still say: "that's so wrong". What's that?
Bad C++ programmer? That's subjective. From my workers at work, developer friends, back in school, my record didn't ever show that I was a bad C++ programmer when they look at my work, or my code. I have worked with rock solid C++ commercial program and that product didn't have problem with memory, or thing like that. Without go too far with this because it becomes a boast, I have to stop here.
Go back to my original idea, I think you probably didn't get it, or you're too ignorant for this to not get it, or you just want to pick a fight. If you look at C++, it obviously works, so don't you tell me to go and implement a C++ compiler to prove my point. C++ has both dynamic allocated object, and statically allocated object. My idea was that to mark object statically so that when it goes out of scope, it'll get discarded. About the GC, it basically does the job of cleaning up all these dynamically allocated objects. So it should not interfere with the statically allocated object. It's like C++ with GC (ofcourse with some modification, probably some product provides GC for c++ already, try search for Smartheap or something like that). Why I said "what stack and heap has anything to do with this?" Your answer was how static and dynamic memory get allocated, not what it has anything to do with this. Here's my point if you don't get it yet. The static memory get allocated in the stack, like you said, and the dynamic memory get allocated in the heap, like you said. So what! Whatever on the stack, get discard when it's out of scope, and the stuff on the heap is GCed.
when did I say GC was a bad idea? Did I say discard the GC in Java? I did recognized that the current GC pauses Java program quite alot for many big Java app (need me to give your example on this?). I also did noted that Java program tend to have large memory foot print, and that could be helped by doing this. The part that helps is the one that reduce the wildly fluctuate memory usage (befed GCed and after GCed). And the reason I think it's possible to alliviate this is to introduce way not to use dynamically generated object beside dynamically generated object (not get rid of it, but provide both functionality). Many C++ program can be written with very few dynamically generated object. I think the GC would be faster if less pointer/handle to scan, and less dynamically generated object for it to process. No, I don't like to hear the "go back to C++" talk. But, anything is good in C++, it'll be nice to bring over to Java. Remember that Java brough many ideas from C++, and there's nothing wrong with that.
vy_ho at 2007-7-5 22:30:22 >
> I think if someone can understand it,
> then that's fine to me.
If you don't use your terminology accurately, different people will think you mean different things. That's why we have terminology.
Furthermore, not knowing the terminology casts grave doubts on your understanding of the problem.
> So say going straight to the JCP to propose something
> is very immature.
I know of no JCPs that have been effected by nattering about them on the forums. You can try to be the first if you like.
> Who care what get allocated where.
The compiler writer ?
> That's
> your way of doing it.
Me and Mr Von Neumann.
> Did you ever program in c++?
Yes. Extensively.
> My suggestion above does not violate any GC memory
> model.
You were talking about a stack based system, though you didn't know it.
> Maybe you did not read it careful enough. And
> what memeory model? Did you know that GC
> memory model was changed lately?
It's always been a GC system. It's currently a mark and sweep, though it may at some early stage have been reference counting (though I don't think so).
> About convincing. Unless you're the one that is
> ignorant, helping someone else to clear his/her point,
> or adding valuable point is the opposite of ignorant.
I'm helping to clarify the fact that you don't know anything about this. Can you write a compiler ? If not, what makes you think you're competent to advise those who can ?
> I have to disagree with your rule of thumb. That's
> called ignorant. Anyone can contribute idea.
"A fool can ask a question that the wisest man cannot answer"
That doesn't make fools any better company. And wise men ask more interesting questions.
> That's why I put
> it up here for people to discuss it.
And see how we leap with joy.
> Bad C++ programmer? That's subjective. From my
> workers at work, developer friends, back in school, my
> record didn't ever show that I was a bad C++
> programmer when they look at my work, or my code. I
> have worked with rock solid C++ commercial program and
> that product didn't have problem with memory, or thing
> like that. Without go too far with this because it
> becomes a boast, I have to stop here.
As you say it's subjective. Subjectively, I think your co-workers might be idiots too.
> If you look
> at C++, it obviously works
If you look at C++, it's a different language.
> so don't you tell me to go
> and implement a C++ compiler to prove my point.
I'm asking you to write a Java compiler to prove that it's worth bothering to do so. If you don't want to, why should we ?
(Snip massive misconception of how C++ memory model works, ignorance of how your solution will affect GC, and whining self-justificatory waffle).
You're writing long, boring posts about how wonderful an idea this is, despite not understanding how Java works, not understanding how C++ works, and not getting any response other than my faintly derisive commentaries. I have a new word for your dictionary: "humility".
Dave.
Just to clarify your dumb idea, tell me what you expect the output of the following program to be:
import java.util.*;
public class Foo {
public static void main(String[] argv) {
List list = new ArrayList();
list.add(o);
Object o = foo(list);
System.out.println("Returned object: " + o);
System.out.println("List size is now: " + list.size());
}
public static Object foo(List list) {
inplace Object o = new String("World");
list.add(o);
return o;
}
}
Erratum: delete the list.add(o); line from the main method.
I don't need to implement Java compiler. Sun already did that. But I can implement a compiler, and an interpretor that can execute my functionality that I described. It won't completely be a "new" java compiler, but that's not a point. It does not have to do all the stuff Java supported to show a point. As long as it does garbag collection, and static/dynamic object, I think that'll show the point.
You think that if I can show that, you'll agree on my point? Or you'll keep going on and on picking on my words?
Many of my points, you do not reply. You say Java and C++ are different. Who says it's the same, but my point was that if C++ can provide this, it means it's possible to do so in Java.
Talking about humble, I don't afraid of being wrong, or admit publicly that I am wrong. I don't call people stupid or idiots. I just try to clear my point, and recognized that it could be wrong, and it needs people's input/help. Humble is always good, but I have a sense that you may have done something in Java compiler and think you know too much, and just disregard people's idea completely just because some particular point people said is wrong, and miss the big picture of what people say.
Anyway, I am not going to write too much, since it's obviously you didn't care on each point that I write, so what good is this.
vy_ho at 2007-7-5 22:30:22 >
> I don't need to implement Java compiler. Sun already
> did that. But I can implement a compiler, and an
> interpretor that can execute my functionality that I
> described.
Ok, off you go then.
> You think that if I can show that, you'll agree on my
> point?
No, because I think it's a stupid addition. But I'll consider the possibility that you at least know what you're talking about.
> Or you'll keep going on and on picking on my
> words?
Language implementation is all about picking on words, so yep, I'll still do that.
> if C++ can provide this, it means it's
> possible to do so in Java.
I didn't say it was impossible, I said it was a bad idea. Java and C++ are different languages with different strengths. Java's is largely its use of a GC memory model, which your ludicrous idea would subvert horribly.
(Snip whiny blah blah)
I think you should be more humble, because you write very long boring posts about a pointless language "feature".
Dave.
From your code:
This shows that you didn't read my message right. Who say you can add an inplace object to a list? Does the list prototype/declaration allow it to add an in place object? Like it did not allow list to add an integer or whatever (other than recently, they autobox the thing, so with inplace, there has to be a defined spec on what to do with this. Such as shoud it be auto-generated a new dynamic object for this, or generate errror. Remember I mentioned about exception for assignment with I/O class, same here, some way of specifying copy constructor is needed for passing inplace object to function. Ofcource, there's many thing needs to spec out for this to work).
With in place object, there must be a different between inplace and handle/pointer in declaration, parameter, etc. You cannot mix them, or use them in place of another, unless there's a spec that states exactly the behavior for this.
I think you try to point out that thing get discarded and then referred somewhere else. Why would you allow that to happen. The "return o" should return a copy of that object (unless error as I said). list.add(o) is already discussed above.
About:
Object o = foo(list);
It shows you didn't read my original message. I did say that care must be taken between pointer/handle and inplace object. Spec has to be written about assignment between inplace object and pointer/handle.
Object o is a handle/pointer, while foo obviously return an inplace object.
You mistaken "static" keyword and inplace. They're not the same here. It should be:
public inplace Object foo(List list)
instead.
If you program extensively in C++, you don't assign "C++ static" object to pointer, or the other way around. You have to derefernce the object. I am not saying this is the way to do it here, but I am saying you cannot do blind assignment.
Oneway to do this is this: (note, this is just one way of doing this).
import java.util.*;
public class Foo {
public static void main(String[] argv) {
List list = new ArrayList();
inplace Object o = foo(list);
System.out.println("Returned object: " + o);
System.out.println("List size is now: " + list.size());
}
public inplace Object foo(List list) {
inplace Object o = new String("World");
//list.add(o);//illegal, changed to:
Object o2 = new String(o); //add a new constructor to String: public String(inplace String s)
list.add(o2);
return o;
}
}
vy_ho at 2007-7-5 22:30:22 >
Oh, great, you can't even use [code] tags properly.
Does this make you any happier ?
import java.util.*;
public class Foo {
public static void main(String[] argv) {
InplaceArrayList list = new ArrayListThatCanTakeInplaceObjectsAsParameters();
inplace Object o = foo(list);
System.out.println("Returned object: " + o);
System.out.println("List size is now: " + list.size());
}
public inplace Object foo(InplaceArrayList list) {
inplace Object o = new String("World");
list.add(o);
return o;
}
}
I'm assuming that it's possible to declare a List type, with whatever syntax you've pulled out of your butt crack, that will accept "inplace" objects.
My original question still stands, what do you expect the output to be ?
Dave.
//comment: inplace Object o = new String("World");This should have been changed to:inplace String o("World");The expected output would be:Returned object: WorldList size is now: 1
vy_ho at 2007-7-5 22:30:22 >
Either your inplace object can't get free'ed until no references to it exist or it will be freed as soon as the last inplace variable passes out of scope.
In the former case, you "leak" the rest of the stackframe while anything has access to a variable belonging to it.
In the latter vase, you permit objects in external collections to mysteriously disappear as their originating variable passes out of scope.
Equally awful either way.
You don't understand a thing about this. That's why I didn't bother answer what the expected output in previous post.
There's no leak or whatever.
The list has to autobox the thing into a dynamic pointer (such as create a new object, and copy the content) for the inplacesupportedlist to work.
The return of the inplace object, if you know C++, unless it's by reference (which you are not allowed to do here), a copy of the object is returned, not the original, and then the content of that get copied into the original variable, and the temporary object get discarded. It's all about spec. Nothing wrong with the program. Now, I know how much you know C++. Kind of wasted my time.
First, your vulgar language shows the type of person you are. And I prefer not to talk to people like that if I have a choice.
vy_ho at 2007-7-5 22:30:22 >
> And I prefer not to talk to people like that> if I have a choice.You do have a choice, so **** off.
IMHO, the ability to allocate objects on the stack, not the heap, would be more cleanly dealt with by the run-time. The VM can prove that some objects referred to in a code block have no references that escape the block. The VM could then chose to allocate these objects on the stack, not the heap.
In the general case, because of polymorphism (a reference of type Foo can refer to an object of any type extending or implementing Foo), it would be /very/ hard to validate this constraint at compile time. Trivial changes to your code (or code it calls) could invalidate the 'non-escaping-pointer' constraint. E.g. a class that regsiters the instance with some other resource during construction, leaking the pointer from your block.
However, since hotspot progressively inlines larger and larger blocks, it should be able to allocate more and more of the objects on the stack, giving progressive gc-related performance enhancements.
To realy get the best out of this, you would need to find some way of eliding out the class references and locks on the object, so that an instance could be allocated on the stack directly as its fields and all methods inlines. Of course, this would also be impossible to check at compile-time, but if you can do it at run-time, it should make some types of code go blisteringly fast.
Anyway, whichever way you cut it, this smells like a run-time optimization, not a compile-time switch to me. If you are still interested, grab the current 5.0 hotspot source and start hacking the optimizer - if this was trivial to do, I would have expected someone at SUN to have done it - it's a fairly obvious fix.
Statically (in C++ sense) allocated objects are placed on the stack. No dispute on this.
>The VM can prove that some objects referred to in a code block have no references that escape the block. >The VM could then chose to allocate these objects on the stack, not the heap.
This will not be possible. The reason is that objects are allocated before used. So, detecting their use before allocation is not easily, if not possible (or have to resort to tradeoff, such as going through all execution path before hand to see if it escape). Oneway is to keep track of allocated objects's reference in a scope to see if it escapes the scope, if so, then all objects in this scope that is referenced by the escaped object also escape this scope (and moved to the new scope if possible).
That's fine for optimization. However, because keeping track of this may cost cpu time (if possible), that's why I propose statically allocated object (remember the word statically is not the same as Java key word static).
Because statically allocated object is marked beforehand by compiler, and sits on the stack, there is significant CPU cost for keeping track of them (no need to find out if they're out of scope). In a sense, this is just the same way primative type was handled, except that it's composite of many other things and functions. Ofcourse, the language is different because there are cases that object content cannot be copied (like iostream class in C++ cannot be copied), spec on how inherited objects can be copied to another one, and functionality to bridge the dynamically allocated object and statically allocated object (such as autobox statically allocated object to dynamically allocated object (create an object dynamically, and copy the content), and the other way around (create statically an object, and copy the content from a dynamically allocated object's handle/reference, note on the null pointer).
So in a sense, the language change helps the VM to do the job better. The VM will have to be modified for this to work.
No change to the GC, because it only deals with dynamically allocated object.
Practically, if GC can be improved to a point that performance and memory is not a problem, then this suggestion can be ignored. The reason is that the suggestion introduces many more concepts and complexities to the language. Personally, I don't have problem with the complexity this feature introduced in C++ (users have to know the different between statically and dynamically allocated object, keep in mind copy constructor, override assignment operator, etc.), but some people may have. Also, the goal of Java was simplicity.
Anyway, this is why I posted this up for discussion. Show that there is one more way to do optimization on the memory and cpu area. It does introduce more complexity to the language, and change to the JVM. If there are other way to optimize better, then should not follow this path. If there isn't, then this could help.
vy_hoa at 2007-7-19 21:34:17 >
Hm, I wonder if I got you right:
Lets look at a code sample like this:
public void foo() {
LargeObject largeObject = new LargeObject();
...
...
}
So in your opinion, the object created by new LargeObject(), remains in memory after the execution
of the method has finished, thats why you want to make it kind of static and mark it for immediate removal?
Well, the instance doesn't stay in the memory, its immediatelly removed by the GC. I think you have a wrong image of the garbage collector. The GC is part of the VM, so whenever a reference to an instance is removed, this happens after the execution of the method, because the stack, which is the only reference to the instance of this LargeObject is removed, the VM checks the reference count of the instance, if its 0 the object is immediatelly freed/removed/whatever from memory. So instances which are no longer used, are always immediatelly removed from memory.
You wonder why there is still a GC called once a while? Well, instances might have circular references, so they would not be removed from memory by the technique described above. But by calling the GC externally, the reference count is re-calcualted and instances with circular references are also removed.
Actually this is the way the GC of Smalltalk works, I think the Java GC is heavily improved since Smalltalk is about 25 years old. But still I think it tries to keep the memory usage of the VM as low as possible.
the opaque, inplace word I used means non-dynamic allocated memory, or as some other said: stack based memory. The VM has to be modified for it to work this way. Right now, only primative types and Object pointer are non-dynamic allocated memory. For example:
int a;
a will be created automatically without: a = new int();
Also, when going outside of the scope of a, it will be safely discarded without the help of virtual machine. Also, allocating a is faster this way (I believe) because less locking. For object, I would have it this way:
public void foo() {
inplace LargeObject largeObject();//now the object already created, there is no object reference here
//largeObject is not a handle/pointer, but it is the object itself, like a in the "int a;"
//for object with constructor different than empty constructor:
inplace MoreObject moreObj(1,2,3);
}
when largeObject is out of scope, it will be discarded right away, thread safe, so it's very fast. And as the result, memory foot print tends to be smaller (because no wait for the GC to kick in).
Now, you may ask how this would work if you want to work with the "normal object". As you may already know, normal object are dynamically allocated, and you refer to them using object pointer or handle. So, copying information between this inplace object and pointer object must be specified out clearly (if you know C++, you know what I mean).
Also, passing inplace object to functions has to be passed by copy. You may argue that this is no better than current way, because thing has to be copied anyway (and worse, because of copy CPU cycle). True for the copy CPU cycle, but C and C++ shows that this is minimal. Also, The copied object will be cleaned out cleanly without garbage collection either.
inplace object will also have problem of not copiable. This is like iostream in C++. The way they solve this problem is using 2 constraints:
1) Have key word saying this object is not copiable (such as having private copy constructor).
2) Passing this object by reference . this is not the same as passing object by pointer like C or Java. Because the reference variable cannot be assigned to another reference variable, it's scoped safe, so the object will be guarantied to be released correctly when it's out of scope.
In Java, we also need way to specify this.
I know for sure that doing this, the GC will have much less work, because most of the object can be created using "inplace" method. This way also allow allocated memory to be much faster because no global locking is needed when looking for memory.
vy_hoa at 2007-7-19 21:34:17 >
But what if:
public class Foo
{
private final static Map theFoos = new HashMap();
public Foo()
{
theFoos.put(new Long(System.currentTimeMillis()),this);
}
public static void main(String[] args)
{
inplace SuperFoo Foo();
//Do some freaky sh*t with SuperFoo
//The second SuperFoo gets anally morphed into a spook-object
}
{
What happens with the **** in the map?
This is a good issue to address. There has to be more than one solution to this. One way is to auto-unbox the object into another copy with dynamic memory allocation. Because as you know, "theFoos" takes an object pointer, not inplace object. So, "this" in this case is a pointer to inplace object, which can be known at run time. Because of this, the object can be copied into dynamic allocated memory. There could be 2 problems to deal with this:
1) Constructor (like your case)
Auto boxing and unboxing will generate infinite number of objects (recursive).
A runtime error could be created for autoboxing or unboxing in the constructor is one way to handle this.
2) None clonable object (if Foo is marked as not supporting autoboxing or unboxing). This has been discussed before in this thread. It just generate exception for these type of object (run time).
When I says autoboxing, unboxing, this is what I mean:
autoboxing: with a pointer/handle to an dynamic allocated object, it will create a copy with inplace object and use that instead. (this is like passing an object in C++, a temporary object will be created, and the copy constructor will be called to copy the content over).
auto unboxing: with a pointer/handle to an inplace object ("this" of an inplace object), or an inplace object, you create a dynamic allocated memory object, and copy the information over.
Your post raise a very interesting point: "this" will be interpreted differently, at runtime for different scenario, depending if this object is inplace or not. It is inplace if the object it points to is inplace, and dynamically allocated if the object is dynamically allocated.
I know that these runtime exceptions are not an ideal solution, so if someone can think of a better way to do this, please share.
On the performance issues, C++ introduce pass by reference. In this case, it's possible, and there will be no problem with it. However, the function that accept pass by reference must be declared so. For this example, "put" of Map must have an overload that accepts pass by reference. Also note that reference here is not pointer. Passing pointer is by value, not reference. An inplace pointer is actually created, then copy over the value, it's the memory the pointer is pointed to is not copied. Also note that a reference variable cannot be assigned to another, except when you initialize a variable that is declared referenced. This could cause a reference to be created that gets initialized to a inplace reference. To prevent this, do not allow a reference variable to be member of a class (it can only be declared inside function or constructor), or not allow them to be declared anywhere at all except as parameters.
Obviously, all of these stuffs has to be clearly thought out for this to work. And scenario like this must be addressed before the thing can be implemented.
vy_hoa at 2007-7-19 21:34:17 >
(yawn)So, have you done any work to implement your "brilliant" ideas?No? Astonishing! One might even imagine that it's because you're too ignorant to do so - but no, surely that couldn't be.Dave.
I'd like to add more comment to my previous post:
>1) Constructor (like your case)
>Auto boxing and unboxing will generate infinite number of objects (recursive).
>A runtime error could be created for autoboxing or unboxing in the constructor is one way to handle this.
This is usual case, and has nothing to do in particular with inplace object. For example, you would get runtime exception in java if in the constructor, you do things like this:
class Foo{
public Foo(){
Foo foo = new Foo();
}
}
>2) None clonable object (if Foo is marked as not supporting autoboxing or unboxing). This has been >discussed before in this thread. It just generate exception for these type of object (run time).
Note that almost all object oriented languages have this feature (not Java, obviously). So the science is already invented. This is nothing new. If someone still think there's problem with this, I would recommend looking at other language that has this feature and learn what they do. From this thread, it seems most questions comes from mixing pointer and object, conversion/reference between them, scope, function parameter, function return value. In case you know C++, you can answer all of these questions yourself.
So far, I haven't seen a problem with the "inplace" feature that hasn't been addressed and solved yet.
vy_hoa at 2007-7-19 21:34:17 >
> So far, I haven't seen a problem with the "inplace"
> feature that hasn't been addressed and solved yet.
Leaving aside your competence, try "it doesn't exist". If you want it to exist, write it. If you don't write it, nobody is going to do it for you, and talking about how much you like the idea won't convince anyone.
I'll take you seriously (and so will others) when you prove this feature has some value by creating it. Until then your vague and inaccurate descriptions of how things work at the moment are sufficient to deter any serious interest.
If, as I suspect, you can't implement this feature because you don't know how, then why do you think you're competent to say how it would "work"? If I'm wrong, why don't you completely show me up by doing a bit of work?
Dave.
I think Dave have put it on a very rude manner and I agree with you that you have not to be a specialist to be entitled to sugest new features. But indeed this opaque Idea seems very opaque to me.
In first place it defeats the Idea of GC, for it is transfering the responsability of keeping track of the objects life from the VM to the programers.
As I have understood, it would create objects that live on the stack, it would mudle the water of how objects are handled by the VM. People are enough confused by this for us to add mor complexity.
Finnaly, once a while people come up with this C++ have X feature but java does not so we need X feature in java. I think it's a gross mistake. Java is not C++ and any new feature should be evaluated on its merits for java in the java context.
May the code be with you.
I agree with you that doing this will add complexity to the language. I have no problem with it in C++, but someone may. I also agree with you that any new feature must be evaluated on its merits for Java.
As I said in one of the posts in this thread, there are plus and minus to this feature. On the plus side, it will help the GC and reduce the gc() pause. On the minus side, it will create more complexity to this. So why I think of this idea? Because after so many generation of Java, it seems Sun still cannot fix this GC pauses, memory hog, memory allocation slowness problem. They improved it, but users still complaint greatly about it.
With regard to transfering the responsibility from VM to programmers, it is not totally so.First, users have to learn the new features, and their limitation. Second, the JVM will manage everything, except the fact that users have to be awared of the type of objects they're working with. I agree that this is just add more complexity. So, as I said in one of the post, if memory allocation and GC implementation improves, this feature will not be needed, except one thing I haven't mention:
Dynamic memory allocation is a blessed, but it is also has its weakness: it flats out the hierarchy of OO design. This means it's a global object, that can be passed around anywhere you want. Using in place object, you gain some of the control of the object scope and hierarchy. I said this just because I want to disect the issue further, not to disagree with your point of view.
Look at a broad view, it would be great if the GC and Java memory allocation is faster, rather than adding this complexity to the language. In C++, it's more complex than without it, but it's the forethought feature, so they have everything in place for it to work. In fact, it's the default way of object creation (without any special tag, like here, you must need something like "inplace", or "opaque"). They also thought out all the constructor problem (mechanism to initialize inplace members object with constructors that accept 1 or more arguments). Pass by reference also helps it to reduce the number of temporary objects and object copy problem. The language also provide copy constructor feature so users will have more power over the object creation and copy. So, adding this feature as an after thought to Java may not be a good idea, and also as computers go faster, better algorithm is found, the problem reduces to none issue.
My conclusion: the concept is possible, and implementable in Java, but this feature is not needed unless there's no way of enhancing the GC any better.
vy_hoa at 2007-7-19 21:34:17 >
> I think Dave have put it on a very rude manner
Fair enough. I think vy_ho is a fool, so yes, I'm being extremely rude.
> and I
> agree with you that you have not to be a specialist to
> be entitled to sugest new features.
I disagree, and I think vy_ho is demonstrating why you need to have an understanding of the internal behaviour of the JVM and the compiler to make this sort of suggestion. Note that:
1. He doesn't understand how the JVM works
2. He doesn't understand how the compiler works
3. He uses incorrect terminology.
In some ways the last point is more important than the others - even if this were an insightful and useful idea, it would be
> But indeed this
> opaque Idea seems very opaque to me.
As it does to me.
Finally, the point I'm trying to make in my rude way, is that I could be nice as pie and terribly encouraging, but since nobody is going to write it for him it won't make a jot of difference either way. If he pulls his finger out and tries to implement this feature, I'll be delighted to give him a hand where I can, even though I think it's of doubtful merit.
But I think it's conceited to think that we care about his fatuous idea otherwise, and pompous to believe that anyone else should implement it for him. Which is why I'm 'quite' hostile.
Dave. Who is not good on Monday mornings, and only slightly less surly on Tuesdays.
vy_ho, a thing I would like to point to you is that your proposed feature will not help the GC for the gc will have to run anyway for still there is all the others objects to clean and probably reorgnizing the remaining objects in the heap is much more expensive than to discard the garbaged ones.
Dave, quoting helloween:
There's a million ways to see the things in life
A million ways to be the fool
In the end of it, none of us is right
Sometimes we need to be alone
Everyone have the righteous right to not be right at Mondays and also at Tuesdays, so I think you can be let pass with that.
May the code be with you.
If you can reduce the number of dynamic allocated objects 80%, how could that be not helping the GC? I am not saying 80% is the actual number. What you said is all or nothing.And you Dave, get the **** off.
vy_hoa at 2007-7-19 21:34:17 >
>
> If you can reduce the number of dynamic allocated
> objects 80%, how could that be not helping the GC? I
> am not saying 80% is the actual number. What you said
> is all or nothing.
>
> And you Dave, get the **** off.
Then you would have a program slower trying to allocate memory in the stack everytime an object is created, one of the advantages of mannaged memory is to postpone the cost of memmory alloc/dealloc to gc time that usualy happens when the system is idle or really needing it, sometimes an aplication does note even live to see a garbage colection. If you have to alloc/dealloc memmory everytime the object is created or goes out of scope you would have a less responsive application.
May the code be with you.
> Then you would have a program slower trying to allocate memory in the stack everytime an object is
> created, one of the advantages of mannaged memory is to postpone the cost of memmory alloc/dealloc to gc
> time that usualy happens when the system is idle or really needing it, sometimes an aplication does note
> even live to see a garbage colection. If you have to alloc/dealloc memmory everytime the object is created or
> goes out of scope you would have a less responsive application.
It's true that the result of this would cause the app less responsive. However, perceivable or not is another matter. It's a trade off between a very long pause and many short pauses. For app written without GC (using other language than Java), this "less" responsive seems to be a none issues. The long pause is the one that many people complaint about. Also remember that long pause by GC does lock up the thing (with latest GC, I think it can do some local memory clean up, but from what I see in Jdk 5, not much diff.), and no other thread can run. With short pauses, other threads can run and go their own businesses.
vy_hoa at 2007-7-19 21:34:21 >
> And you Dave, get the **** off.No.So, do you know how to build this yourself? Is anyone here going to build it for you?......That's funny, I didn't hear a 'yes' in the chorus...What a loser.Dave.
What a shameless act from this guy. Just want to point out to other people (no, not you Dave, you don't deserve a conversation from me) how low a life this guy has (and maybe you have a good laugh)
1) First, if you report a bug, or suggest a feature, there's no saying that you have to implement it. (someone has said this, but this guy is probably retarded and did not listen or understand. No, this is not an insult, it's fact)
2) I know how to build this. Why would I NEED this? And why would I do this FOR me. Obviously I don't need this more than other millions of people who uses Java out there. It would be stupid to build this FOR me, if not for my own FUN or PROFIT.
3) Simple concept like this, and an "C++ experienced" guy like that cannot understand, and I have to point out many of his errors both in code and in logics. I also clear ALL questions regarding the concept, and he still does not get it. What's the dictionary word for this? Oh, many, but try "retarded". Again, it's not an insult, it's fact.
4) The guy try to tell me that I have to understand JVM to suggest this. Yes, I know some of the JVM concepts. Not everyone masters all JVM technology (if any). But the guy does not understand the abstraction between excecution environment and programming language. That is you can talk about language but not about how internally the JVM works. That's why there is specification about languages and there is specification about machines (Machine in general, such as Intel's, Amd's, JVM, etc). In fact, it's possible to compile java to machine code that runs under native environment, and not JVM.
There are more, but you get the idea. This guy probably cannot get it. So it's probably a waste effort to point out ALL of his .... retardness.
So where else can you laugh at?
Looking at this guy's resume, you see that he has worked at many places, short terms. Probably contracts. That may point to his frustration in life. Ironically, he wrote a computer book. Could you believe that this is a guy that write a book? What a messed up world it is. I am actually laughing when writing this. More ironic, his resume shows what his accomplishments are, and that's nothing compare to his arrogant. There's an adage that say something about the more you know, the more humble you are. Reverse that, and you know his mental state. My advice for people like this: go see a psychologist.
vy_hoa at 2007-7-19 21:34:21 >
I certainly had a good laugh. I can't speak for anyone else.
Addressing your conveniently numbered points:
1. If you wish to report a bug or suggest a feature to Sun, you should use the bug database; that's what it's for. Alternatively you raise a JCP. I have never heard of any feature suggested in the forums becoming part of the language, nor would I expect it to.
2. "Why would I NEED this"? Surely the question is why would anyone need this? It's a clueless pointless waste of space.
3. I don't understand precisely what you want because you haven't expressed it in rigorous terms. Certainly I understand the gist of what you're after - but I think it's a stupid idea, largely because of exactly those details that you're not considering.
4. You don't have to understand the JVM to suggest this, but you have to understand the JVM if you want to understand the arguments for or against it. Since you evidently don't, it seems rather pointless arguing with you, so I've resorted to abuse for my personal entertainment (it's working very well).
"retardness" - so very nearly a word.
"Looking at this guy's resume, you see that he has worked at many places, short terms. Probably contracts." - duh - I'm a consultant. We get our jobs in contract form, and it's terribly lucrative.
"More ironic, his resume shows what his accomplishments are, and that's nothing compare to his arrogant." And your achievements are?
Nope, I haven't achieved much, I expect there are plenty of users of the forum who're vastly more competent than me, far more intellectual, and undoubtedly nicer people.
But I haven't seen any of the real giants commenting on your clueless idea. It's lovely to see you so attached to it. You're so witless.
Dave.
