1 2 3 Previous Next 34 Replies Latest reply: Oct 20, 2004 8:25 AM by dcminter Go to original post RSS
      • 15. Re: Propose adding opage/inplace object instance to the language
        dcminter
        And I prefer not to talk to people like that
        if I have a choice.
        You do have a choice, so fuck off.

        • 16. Re: Propose adding opage/inplace object instance to the language
          843853
          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.
          • 17. Re: Propose adding opage/inplace object instance to the language
            843853

            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.






            • 18. Re: Propose adding opage/inplace object instance to the language
              843853
              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.
              • 19. Re: Propose adding opage/inplace object instance to the language
                843853
                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.










                • 20. Re: Propose adding opage/inplace object instance to the language
                  843853
                  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 crap in the map?
                  • 21. Re: Propose adding opage/inplace object instance to the language
                    843853

                    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.



                    • 22. Re: Propose adding opage/inplace object instance to the language
                      dcminter

                      (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.
                      • 23. Re: Propose adding opage/inplace object instance to the language
                        843853

                        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.





                        • 24. Re: Propose adding opage/inplace object instance to the language
                          dcminter
                          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.
                          • 25. Re: Propose adding opage/inplace object instance to the language
                            notivago

                            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.
                            • 26. Re: Propose adding opage/inplace object instance to the language
                              843853

                              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.

                              • 27. Re: Propose adding opage/inplace object instance to the language
                                dcminter
                                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.
                                • 28. Re: Propose adding opage/inplace object instance to the language
                                  notivago

                                  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.


                                  • 29. Re: Propose adding opage/inplace object instance to the language
                                    843853

                                    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 fuck off.