Project proposal: ROI

[Peter Lawrey]

Hi,
   I highly recommend creating a prototype as a library showing the
functionality first and adding syntactic sugar later.
It should be possible to do this with static factory methods and a
WeakHashMap/WeakReferences initially and then make it more
efficient/cleaner/builtin later.
This would make back porting to older versions easier as well.

ValuableStuff vs = ROI.recycle(ValuableStuff::new);

You might like to think about objects created with non default
constructors. Like

final class ROI {
   static <T, A> T recycle(Function<A, T> creator, A arg);
}

class ValuableStuff {
    public ValuableStuff(Config config) {
}

ValuableStuff vs = ROI.recycle(ValuableStuff::new, config);


Regards,
   Peter.

On Fri, 1 Apr 2022 at 10:26, Eric Vergnaud <eric.vergnaud at wanadoo.fr> wrote:

> In a similar responsible inspiration, I would like to introduce the ROI
> project, and submit it for approval by the OpenJDK community.
>
> ROI stands for Recycle Obsolete Instances, and introduces the following
> interface:
>
> public interface Recyclable<T extends Recyclable> {
>
>         default T recycle(T obsolete) { return obsolete; }
> }
>
> Unlike regular instances, Recyclable instances eligible for GC are not
> immediately disposed.
> Instead, they are moved to a new memory zone called SLS, standing for
> Second Life Space.
>
> Thanks to the default method above, implementing the Recyclable interface
> may be as simple as the following:
>
> class ValuableStuff implements Recyclable< ValuableStuff > {
> }
>
> This in turn enables a completely new syntax for instantiating objects:
>
> ValuableStuff vs = recycle ValuableStuff();
>
> Please note the introduction of the new ‘recycle’ keyword.
>
> When utilized, the ‘recycle’ keyword forces the JVM to look for an
> existing instance in the SLS.
> If one is available, its recycle method is invoked, it is removed from the
> SLS, and the result is returned to the caller.
> If none is available, the JVM falls back to the historical allocation
> mechanism.
>
> Please note that ROI usually stands for Return On Investment, which seems
> particularly appropriate here: once you’ve heavily invested in constructing
> an object, you want to maximize the return on that investment.
>
> I hope the OpenJDK community will be supportive.
>
> Thanks,
>
> Eric
>
>
> > Le 1 avr. 2022 à 09:33, Erik Osterlund <erik.osterlund at oracle.com> a
> écrit :
> >
> > This is a great idea Magnus.
> >
> > It is so crucial for the environment that we recycle as much as
> possible. The great thing
> > with green threads, is that unlike normal threads, they can be recycled
> by the GC, which
> > is ever so important for the environment. However, I think that as part
> of this project,
> > we should make recycling of green threads even more aggressive. I
> propose a probabilistic
> > approach that lets the GC find not just provably garbage green threads,
> but also
> > "probably garbage" green threads. I'm sure the user can just create a
> new thread
> > in the unlikely scenario that my algorithm is occasionally inaccurate,
> because everyone
> > is running stateless apps nowadays anyway. Right?
> >
> > The algorithm will traverse green thread roots and their transitive
> closure, looking for
> > strings that can be associated with probably garbage work that is likely
> to be just discarded,
> > such as "BTC", "ETH", etc. ZGC will then use a new "probably garbage"
> color in its pointers,
> > to paint the transitive closure of green threads as "probably garbage".
> Then the entire
> > object graph of such green threads can be immediately recycled. In the
> unlikely event
> > that such a pointer is loaded by another thread, the load will raise a
> PrematureRecyclingException.
> >
> > I think this idea could greatly benefit the environment, and promote
> recycling to a new level.
> >
> > /Erik
> >
> >> -----Original Message-----
> >> From: discuss <discuss-retn at openjdk.java.net> On Behalf Of Magnus Ihse
> >> Bursie
> >> Sent: Friday, 1 April 2022 07:52
> >> To: discuss at openjdk.java.net
> >> Subject: Call for Discussion: Project proposal: Greenfields
> >>
> >> With Project Loom[1] getting closer to delivery, we will soon have a
> world
> >> where even simple Java programs might use millions of threads.
> >> This will, in effect, mean a world-wide multiplication on the number of
> >> threads in Java programs by several magnitudes! This might seem like a
> >> fantastic win for the Java eco-system, but we are forgetting the
> effects on
> >> the real eco-system.
> >>
> >> As you might or might not be aware of, the textile industry is one of
> the
> >> heaviest polluter in the world[2]. Adding billions upon billions of new
> threads
> >> to this world seem like environmental arrogance.
> >>
> >> I therefore propose we start Project Greenfield, which will research the
> >> reintroduction of Green Threads, and study how much pesticide and
> fertilizer
> >> use will rise due to Project Loom. Project Greenfields will also develop
> >> prototypes to lower pesticide, fertilizer, and water use for Java
> programs
> >> that need to create millions of threads.
> >>
> >> Project Greenfields will deliver its first prototype in exactly one
> years time,
> >> April 1, 2023. If this is successful, we can retarget the project for
> the
> >> upcoming year, to look at the CO2 cost associated with Java bean
> production.
> >>
> >> /Magnus
> >>
> >> [1] https://openjdk.java.net/projects/loom
> >> [2]
> >> https://www.europarl.europa.eu/news/en/headlines/society/20201208STO
> >> 93327/the-impact-of-textile-production-and-waste-on-the-environment-
> >> infographic
> >
>
>