No post body was provided.
Untitled topic
1–8 of 8 posts
Re: undefined
#2One note - if you ever have to write middle ware (or a garbage collector), avoid any code calling custom implementations like hashCode/equals. A variant of Collections.newSetFromMap(IdentityHashMap...) should replaces all Sets in the example. That doesn't address any concurrency issues, of course.
Re: undefined
#3> the stack will hold all of the variables – this includes the local and the method call information
That's not quite right. Method call data is passed in the local variable fields of the method's frame, not on the stack.
Re: undefined
#4I found this a little confusing. The article contains several simplistic examples of garbage collection algorithms - written in Java! A tantalisingly meta concept, but snatched away half way through when the article clarifies that of course you can't write your own garbage collection in Java and plug it into the JVM. You need native code.
Another nit is that at the top of the article is a link to another article on "Understanding How to Use Cryptography in Java" which is claimed to be "a good starting point to taking on this adventure." Personally I could not see any connection between the two subjects, which made me feel that some editor type stuffed that in there in an attempt to juice their page views.
Re: undefined
#5> the stack will hold all of the variables – this includes the local and the method call information That's not quite right. Method call data is passed in the local variable fields of the method's frame, not on the stack.
The frame data is still stored on the stack with the parameters being passed residing in the first part of the locals section of the frame, that way as the values already residing on the stack can overlap into the next stack frame. The spec doesn't specify that is has to be this way, so technically stack frames can be in non contiguous memory but afaik this is not common.
Re: undefined
#6This honestly kinda feels like it was written by an ai?
Re: undefined
#7I found this a little confusing. The article contains several simplistic examples of garbage collection algorithms - written in Java! A tantalisingly meta concept, but snatched away half way through when the article clarifies that of course you can't write your own garbage collection in Java and plug it into the JVM. You need native code. Another nit is that at the top of the article is a link to another article on "…
I guess this is a sort of gentle introduction to "how GC works" for Java devs.
For more realistic usage, perhaps poking the Boehm-Demers-Weiser or the likes is better, unless you want to hack the JVM code, because the GC API isn't exposed to developers.
Re: undefined
#8I found this a little confusing. The article contains several simplistic examples of garbage collection algorithms - written in Java! A tantalisingly meta concept, but snatched away half way through when the article clarifies that of course you can't write your own garbage collection in Java and plug it into the JVM. You need native code. Another nit is that at the top of the article is a link to another article on "…
I guess this is a sort of gentle introduction to "how GC works" for Java devs. For more realistic usage, perhaps poking the Boehm-Demers-Weiser or the likes is better, unless you want to hack the JVM code, because the GC API isn't exposed to developers.
It lacks any concurrency handling, even though there is a section about it. The attempt to use some, e.g. RefCountedObject, performs a proper transgression - 'data' field being non-volatile and modified within a synchronized block but read outside.